Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах
Skip navigation

IPv6 свързаност за Софийския университет "Св. Климент Охридски"

Настоящата публикация има за цел да предостави на вниманието на българските интернет потребители опита по внедряването на адресния протокол IPv6, натрупан от специалистите от направление “Мрежи и комуникации” на Университетския изчислителен център на Софийския университет “Св. Климент Охридски”.
27993 прочитания, 5

Настоящата публикация има за цел да предостави на вниманието на българските интернет потребители опита по внедряването на адресния протокол IPv6, натрупан от специалистите от направление "Мрежи и комуникации" на Университетския изчислителен център на Софийския университет "Св. Климент Охридски". Въпреки ограничения обем на публикацията старанието е било да се даде максимално пълно описание на процеса и да се маркират най-важните проблеми, които следва да се преодолеят в хода на миграционния процес.

1. Предпоставки за внедряване на IPv6

Протоколът IPv4 (RFC 791), по който се осъществява маршрутизацията и адресацията на мрежови устройства в съвременните компютърни мрежи, е разработен през 70-те години на XX век. Той дефинира адреси с дължина 32 бита, което ограничава адресното пространство до 232 броя уникални IP адреса. Стръмно експоненциалният растеж на броя на възлите (хостовете) в Интернет от средата на 1990-те (Фиг. 1) закономерно доведе до тяхното изчерпване. Към момента на написване на този материал последните неалокирани блокове от IPv4 адреси в регистъра на IANA (организацията, която разпределя на високо ниво IP адресния номерационен план в Интернет) са в процес на раздаване на крайните потребители от регионалните (RIR) и локалните (LIR) интернет регистри.



Фиг. 1 Растеж на Интернет хостовете през годините

Очакванията са в следващите години броят на устройствата, свързани към Интернет и изискващи уникален IP адрес за осъществяване на комуникация, да расте лавинообразно. Най-значимата причина, подклаждаща такива очаквания, е интензивното предлагане на пазара на потребителска и най-вече битова електроника, на устройства, чиито функционалности и дистанционно управление са базирани на мобилните комуникационни технологии от четвърто поколение. 4G технологиите се очаква да бъдат главните потребители на уникални IP адреси. Типични представители на тези иновативни потребителски продукти са интелигентните електрически уреди и системните за отдалечено поддържане на дома (smart home). Засиленото им предлагане и използване ще засилят търсенето на все по-големи количества уникални IP адреси, което, от своя страна, ще направи внедряването на новия адресен протокол — IPv6, неизбежен процес. В този случай адресният протокол IPv6 решава проблема с нарастващото търсене на уникални IP адреси поради факта, че използва за адреси 128-битови цели числа (RFC 4291). IPv6 адресите се задават в потребителския интерфейс за настройки на мрежовите функции на операционната система чрез описание с шестнадесетични цифри (за краткост на записа). По стандарт всяка група от четири последователни шестнадесетични цифри се отделя от съседните й групи с двуеточие например, fe80:43e3:9095:02e5:0216:cbff:feb2:7474. При наличие на добра организация на процеса на разпределяне на IPv6 адресите от RIR и LIR субектите за нуждите на адресиране на устройствата на крайните потребители в Интернет, така дефинираното адресно пространство от 128-битови уникални адреси би следвало да се разглежда като практически неизчерпаем номерационен ресурс. И наистина такова разглеждане има място, защото техният брой е 2128.

Въпреки че адресното пространство, дефинирано в рамките на новия адресен протокол, би решило проблема с уникалната идентификация на всяка устройство, включено към Интернет, и би осигурило директен достъп към него, това не е главното негово предимство. Адресният протокол IPv6 преди всичко предоставя нови функционалности и бъдещи възможности за създаване на нови комуникационни протоколи, приложения и услуги. Ето кратък списък с някои най-важните функционалности, налични към момента:

  • Възможност за автоматично самоконфигуриране на хост в локалния Ethernet сегмент (RFC 4862), т.е. операционната система автоматично си назначава уникален IPv6 адрес и открива кой е подразбиращият се маршрутизатор. Подобна функционалност в IPv4 е трудно постижима. Въпреки наличието на тази възможност в IPv6 е предвидена и версия на протокола DHCP (DHCPv6) чрез която операторът на дадена локална мрежа може да задава специфична хост информация;
  • Заглавната част в IPv6 (header) е по-добре структурирана за прочит и обработка в сравнение с тази в IPv4. Тя е с фиксирана дължина от 40 байта и допуска до шест допълнителни (разширени) „заглавия" (extension headers) (RFC 2460);
  • IP security (IPsec) е интегрална част от структурата на IPv6 пакетите за разлика от реализацята й в IPv4. За да имаме IPsec базирана комуникация в IPv6, е достатъчно да включим две от допълнителните заглавия: Encapsulating Security Payload (ESP) и Authentication Header (AH). IPsec също така е задължителна част от комуникацията при реализиране на мобилен хост или мрежа (Mobile IPv6 — MIPv6), а в новите версии на протоколи за динамична маршрутизация като OSPFv3 съзнателно е пропуснат вътрешен за протокола удостоверителен механизъм, защото се разчита той да бъде предоставен от IPsec като удостоверява участниците в обмена на маршрутна информация;
  • Mobile IPv6 (MIPv6) поддържа мобилност на мрежовите възли (роуминг на свързаност и адресация), при придвижването им от една мрежа в друга, без да се губи IP свързаност (RFC 3775). За сравнение, поддръжката на подобна мобилност в IPv4 (RFC 3344) е ограничено от протокола ARP, който в IPv6 е заменен с Neighbor Discovery (RFC 4861);
  • IPv6 по-подробно, точно и рационално дефинира качеството на услугите (QoS) и позволява по-лесна приоритизация на трафика чрез задаване на стойности на полетата Traffic Class и Flow Label в заглавната част на пакетите, което е особено полезно за повишаване на качеството на IP телефонията (VoIP), мултимедийните онлайн услуги в реално време и скоростта на обмен на данни в мрежи, обслужващи клъстерни услуги;
  • Въпреки че IPv6 не притежава обратна съвместимост с адресния протокол IPv4 и внедряването му изисква значителни структурни нововъведения и немалко финансово обезпечение, той създава нови бизнес модели в сферата на комуникациите, води до натрупване на значително количество нови знания и идеи, а това, от своя страна, спомага за глобалното развитие на телекомуникационния сектор.

2. Описание на принципните трудности при преход от IРv4 към IPv6

Няма как да бъде извършен рязък преход от IPv4 към IPv6 базиран Интернет. Чисто технологично не е възможно да се извърши такава голяма по обем внедрителска дейност за кратък период от време, без да се наруши целостта на Глобалната мрежа. Единственият разумен механизъм за преход от IPv4 към IPv6 е да се направи постепенен и плавен преход от единия адресен протокол към другия, като по време на преходния период се използват едновременно и двата адресни протокола. Технически и финансово неоправдано е пакетите на всеки един от адресните протоколи да се транспортират в собствена за протокола физическа преносна среда. Реализирането на подобна схема би разделило физически Интернет на две части — IPv4 базиран Интернет и IPv6 базиран Интернет, което е неиздържана технически, а и дори политически постановка на задачата за преход към новия адресен протокол. Затова се възприема, че в преходния период транспортирането на пакетите по двата протокола ще става в една и съща физическа преносна среда. Използването на споделена среда улеснява прехода, защото позволява системата за глобалната маршрутизация (базирана на маршрутизатори, обменящи информация за достъпните маршрути в Интернет по протокола BGP4/4+), да се надстрои „в движение" с малки финансови разходи и кратки прекъсвания в нейни локални сегменти. Повечето производители на маршрутизатори и приложен софтуер за тях позволяват техните продукти да се конфигурират така, че едновременно да машрутизират IPv4 и IPv6 трафик, а конфигурациите за това са част от един единствен софтуерен продукт. Това означава, че в повечето случаи няма да се налага закупуването на отделен маршрутизатор за маршрутизацията на IPv6, защото най-вероятно използвания към момента може сравнително лесно и евтино да се пренастрои така, че да маршрутизира IPv6 пакети по вече установените комуникационни канали. Съгласно оценки на различни експерти само между 7 и 10% от маршрутизаторите, участващи в глобалната маршрутзация в Интернет, ще трябва задължително да бъдат подменени с нови модели, за да маршрутизират IPv6 трафика. Следователно поне на ниво глобална маршрутизация преходът към IPv6 вероятно няма да бъде толкова труден, а освен това той вече е в напреднал стадий.

От гледна точка на доставката на IPv6 свързаност за крайни клиенти обаче нещата не стоят толкова просто. Причината е, че разпределението на свързаността за крайни клиенти се прави на база на политики за скорост, политики за достъп (пакетна филтрация например), VPN решения и т.н. Тук трябва да споменем и морето от приложен софтуер с мрежови функции, което също следва да се адаптира към IPv6. Разбира се, и тук решението е да има преходен период, в който да се използват едновременно и двата адресни протокола, но следва да се подчертае, че приложният софтуер с отворен код е много по-готов да покрие това изискване. При свързването на крайни клиенти към IPv6 Интернет има твърде специфични особености. Например, много по-лесно е малка организация да извърши преход към използване на IPv6, отколкото това да стане в един доставчик на Интернет свързаност за крайни клиенти. Казано по друг начин, много по-лесно е за един доставчик на Интернет свързаност да осигури IPv6 свързаност на бизнес-потребители си, отколкото на домашните си клиенти. Причината е използването на специфични протоколи за пренос и специализиран хардуер за достъп на домашните клиенти до мрежата на доставчика (добър пример за описания проблем е технологията PON, чието настройване за поддръжка на IPv6 би отнело години, особено ако е била внедрена, без да се предвиди преминаване към новия адресен протокол в бъдеще. Друг пример е оборудването за DSL). Българската Интернет инфраструктура е сравнително модерна и много от доставчиците на свързаност за домашни потребители използват за достъп до компютрите на крайните си клиенти Ethernet протокол. В такива мрежи доставката на IPv6 за домашни потребители би била значително по-евтина, лесна за реализация и почти естествена, защото IPv6 е напълно съвместим с логическото ниво на пренос в Ethernet мрежи.

Тъй като мрежата на Софийския университет (СУ) е автономна структура, базирана изцяло на Ethernet свързаност в отделните нейни локални подмрежи (примерно мрежите на ниво «факултет»), доставянето на IPv6 свързаност до крайните потребители не бе задача с изключително високо ниво на трудност. Допълнително улеснение бе е и фактът, че свързаността на университета с Интернет доставчиците му бе (и е) базирана само на локални Ethernet сегменти за напречна свързаност (повечето от които са реализирани през MAN — Metropolitan Area Network). Именно наличието на такава всеобхватна Ethernet структура позволи бързото, евтино и безпроблемно внедряване на новия адресен протокол. Що се касае до маршрутизацията на IPv6 трафика едновременно с този за IPv4, преходът тук бе изключително улеснен от факта, че всички гранични маршрутизатори и маршрутизатори за достъп на клиентски мрежи до опорната мрежа на университета използват операционна система Linux и Quagga за маршрутизиращ софтуер, чрез който се реализира обмена на маршрутна информация по протокола BGP4+.

От гледна точка на терминологията, подобното на описаното по-горе съвместно използване на двата адресни протокола, се нарича механизъм на свързване «dual-stack» и той е свойство преди всичко на операционната система, която следва да има възможност да използва едновременно и съвместно в своето ядро IPv4 и IPv6. Тъй като в много от приложния софтуер има настройки за осъществяването на Интернет свързаността за достъпване на определени отдалечени услуги, този тип софтуер също следва да разбира езика на двата адресни протокола. Последното пък означава, че механизмът «dual-stack» трябва да се разшири до целия използван приложен софтуер с мрежови функции. В рамките на механизма «dual-stack» за съвместно използване на IPv4 и IPv6 съществува стандартизиран метод за избор на адресен протокол, когато една услуга е достъпна едновременно и по двата адресни протокола. Най-важното в този стандартизиран метод е, че с предимство се избира достъпът до услугата по IPv6. Как става този избор? Все едно дали едно софтуерно приложение работи в режим на «dual-stack» или не — за да достъпи дадена услуга, то най-често праща запитване до системата за имена в Интернет (DNS), за да разбере IP адреса, на който търсената услуга се предлага. Когато описанието за нея в DNS включва едновременно и IPv4, и IPv6 адреси, а приложението, което е заявило информацията, използва дизайн с механизъм «dual-stack», първо се инициира връзка към посочения IPv6 адрес и единствено при неуспешно свързване се пристъпва към връзка с IPv4 адреса на услугата.

Всичко написано дотук изглежда сравнително лесно приложимо на практика, ако изключим трудностите при закупуването и настройването на специализирания хардуер за комутация, който е част от всяка съвременна потребителска мрежа. В рамките на мрежата на СУ се използват маршрутизатори, базирани на Linux операционна система, и преходът към «dual-stack» там бе сравнително лесен. Не така обаче стоеше въпросът с някои специфични настройки на комутацията в рамките на Ethernet протокола (известна като «switching»). Много от специализираните комутатори не поддържат филтрация или приоритизация на база на IPv6, а други, които имат възможност, изискват софтуерна актуализация и реконфигуриране, но това налага не само прекъсване на свързаността в сегментите, свързани към комутатора, но и закупуване на софтуерната актуализация. Що се касае до приложния софтуер, преходът към «dual-stack» на сървърния софтуер премина сравнително гладко, защото повечето сървърни системи използват софтуер с отворен код, който е с дизайн за «dual-stack» по подразбиране.

3. Заявяване и получаване на IPv6 адресен ресурс

Тази тема нарочно е отделена от горната, защото тя не касае само миграцията от IPv4 към IPv6 базиран Интернет, но ще бъде актуална винаги при бъдещето разширяване на комуникационните мрежи с нови устройства, изискващи все повече уникални IPv6 адреси. Освен това заявяването и получаването на IPv6 адресен ресурс изисква известно познаване на материята и самооценка и затова следва да бъде описано самостоятелно.

IP адресите (в това число IPv6 адресите) са публичен ресурс и върху тях няма права на собственост (вещно право). Следователно е тотално неправилно да се говори за „закупуване" на IPv6 адресно пространство. То може да бъде предоставено само за временно ползване на организация или потребител, участващи в Интернет, при определени договорни условия. Следователно е по-правилно да говорим за раздаване или разпределяне на наличния IPv6 адресен ресурс между участниците в Интернет. Разпределянето на IPv6 адресния ресурс става централизирано. Организацията IANA (http://www.iana.org) е централният орган, отговорен за разпределянето му. От своя страна, тя сертифицира свои контрагенти, базирани на регионален принцип и наречени „регионални интернет регистри" (на английски всеки такъв контрагент се нарича Regional Internet Registry — RIR). Те имат за задача да разпределят предоставеното им IPv6 адресно пространство между крайните потребители в своя регион на действие. Регионален интернет регистър за Европа е организацията RIPE (http://www.ripe.net), базирана в Амстердам. От своя страна, RIPE има структура на организация с членове, като всеки такъв член се нарича LIR (Local Internet Registry). Тези членове са и локални партньори на RIPE и помагат за по-лесното разпределяне на адресни ресурси за нуждите на крайните потребители. Тук има една особеност — LIR обикновено е субект, който е Интернет доставчик. RIPE разпределя адресните ресурси като автономни. Това означава, че LIR организацията, която получи адресното пространство, ще се грижи сама за неговото локално разпределяне и сама ще определя как ще се маршрутизира трафикът от и към него в Интернет. Когато даден субект стане член на RIPE и получи статус на LIR, той автоматично получава IPv6 автономен адресен ресурс в размер на 296 уникални IPv6 адреса.

В каталога на RIPE, публично достъпен за преглед на съдържанието чрез услугата, наречена RIPE DB (whois.ripe.net), това заделено адресно пространство за нуждите на LIR се каталогизира като адрес на мрежата и дължина на мрежовата маска, записвани един след друг с разделител «/» (например: 2a01:288:8000::/32). Дължината на мрежовата маска (в примера е /32) са битовете, които са фиксирани като стойност във всеки един IPv6 адрес на описаната мрежа. Друго важно административно свойство на мрежата, с която тя се каталогизира в RIPE DB, е нейният статус за маршрутна обединяване и управление.

Мрежите на всички LIR членове имат обикновено статус «ALLOCATED PA» (PA — Provider Aggregatable), но са възможни и по-специфични статуси. Тъй като се предполага, че LIR субектите имат за дейност доставка на свързаност, те получават това огромно пространство адреси (296) за нуждите на своите крайни потребители, които не се нуждаят от автономен адресен ресурс. Предполага се, че LIR субектите няма да раздробяват тяхното адресно пространство от гледна точка на излъчването на информация за маршрутите до него в BGP4+. Информацията за маршрута до дадена мрежа в протокола BGP4+ се нарича на мрежови жаргон «префикс» («prefix») и споменатото условие за лимитиране на дробенето гарантира по-малко префикси (информация) в глобалната маршрутна таблица, която се формира и разпространява върху маршрутизаторите на участниците в Интернет. Именно за това статусът на мрежата, предоставена на LIR, е «ALLOCATED PA» - този, който я излъчва, следва да я агрегира до възможния минимум от префикси — един.

Някои крайни потребители обаче се нуждаят от автономно адресно пространство, което не зависи от избора на доставчик на свързаност. По този начин те определят сами своята маршрутизация на трафика от и към Интернет и през кои доставчици на свързаност да става тя. Ясно е, че това адресно пространство няма как да бъде част от мрежа на LIR поради изискването за агрегацията на маршрутната информация, излъчвана в BGP4+. Именно затова RIPE са предвидили възможността за предоставяне на автономен ресурс за крайни потребители, които не са LIR субекти, като този ресурс включва уникално IPv6 адресно пространство с по-малка размерност, характеризиращо се със статус «ASSIGNED PI» (PI — Provider Independent). Този статус се посочва в каталога на RIPE заедно с описанието на адреса на мрежата и дължината на мрежовата маска.

За момента минималният мрежови IPv6 сегмент за автономно ползване от крайни клиенти е с размер 280 уникални адреса или дължината на мрежовата маска е 48 бита (например: 2001:67c:20d0::/48 е точно такава мрежа и маска). Трябва да се има предвид и начинът на заявяване и получаване на подобно автономно IPv6 пространство. За да може даден субект да получи IPv6 адресно пространство със статус «ASSIGNED PI», той следва да покрие изисквания на RIPE относно категоризирането му като «End User». Например едно от изискванията е да има съдебна регистрация от съд в Европа, друго е да докаже, че ще маршрутизира алтернативно предоставеното му адресно пространство през поне два независими доставчика и да разполага с маршрутизатори, участващи в глобалния обмен на маршрутна информация по протокола BGP4+. Освен това получателят на автономния адресен ресурс следва да сключи договор за използването му директно с RIPE или с някой LIR и да заплаща годишна такса за поддръжка на адресния ресурс в информационните системи на RIPE. При неплащане на таксите или непокриване на условията на RIPE за категоризацията му като «End User», крайният потребител следва да върне предоставеното му автономно IPv6 адресно пространство.

Следователно не всеки краен потребител може да получи независим IPv6 адресен ресурс. Тези крайни потребители, които не могат да получат автономен ресурс, тъй като не са квалифицирани като «End User» от RIPE, следва да използват част от IPv6 адресното пространство на своя Интернет доставчик, който най-вероятно има статус на LIR и разполага с голям мрежови сегмент от уникални адреси. Неудобството в случая е, че при всяка смяна на доставчика, крайният потребител следва да получи нови адреси от новия доставчик и да ги конфигурира в своите устройства.

Когато внедряването на IPv6 в мрежата на СУ трябваше да започне (през зимата на 2006 г. и пролетта на 2007 г.), първата задача, която трябваше да се реши, бе откъде и как да се намери IPv6 адресно пространство и IPv6 свързаност. По това време RIPE предоставяха IPv6 адресни ресурси единствено на свои членове с LIR статус. Не бе предвидена подобна възможност за организации със статус на «End User». Причината бе, че не съществуваше съгласие и официален документ, на база на който да се определи редът на предоставянето на независим (автономен) IPv6 адресен ресурс на крайни потребители със статус «End User» и как изобщо да се дефинира този статус. Едно възможно решение бе да се изчака докато членовете на RIPE постигнат съгласие и бъде оформи документ, на базата на който на крайни потребители със статус «End User» да се предоставят автономни IPv6 адресни ресурси, категоризирани като «ASSIGNED PI».

Нямаше яснота обаче колко точно време ще отнеме съгласуването на съдържанието на документа, а и не бе уместно да се губи време и да се отлага обучението на перспективни млади специалисти. Затова се реши да се заеме за временно ползване част от IPv6 адресното пространство на някой от доставчиците на Интернет свързаност на университета. По това време те бяха два — БИОМ (Българската изследователска и образователна мрежа) и Спектър Нет.

БИОМ бяха LIR (и все още са) и имаха собствена IPv6 мрежа с дължина на мрежовата маска 32 бита (както се полага на LIR). Имаха и високоскоростен канал за връзка към IPv6 Интернета в рамките на проекта GEANT2. Спектър Нет бяха LIR, но нямаха алокирано автономно IPv6 адресно пространство. При тези обстоятелства може би бе най-естествено да се поиска от БИОМ да ни предоставят за временно ползване част от тяхното IPv6 адресно пространство. Това обаче нямаше особен смисъл поради простата причина, че нямаше да доведе до максимално натрупване на знания и практики, защото БИОМ вече имаха опит по маршрутизацията на IPv6 трафик (по това време Пловдивския университет имаше вече IPv6 свързаност и адреси от мрежата на БИОМ).

Реши се да се подходи колаборативно и да се стимулират комерсиалните доставчици на Интернет свързаност да изградят своя IPv6 свързаност, да получат свое IPv6 адресно пространство и да започнат комерсиален транзит на трафик по новия адресен протокол. Именно с тази цел бяха започнати преговори със Спектър Нет (следва да се изкажат особени благодарности на колегите Теодор Захов, Петър Щинков и Таня Димитрова за проявеното разбиране). В резултат на положителния изход от преговорите Спектър Нет, в ролята им на LIR, получиха полагащото им се IPv6 адресно пространство: 2a01:288:8000::/32 и от него за нуждите на СУ бе алокиран адресния сегмент 2a01:288:8000::/35. Предстоеше да се формира префикс за този адресен сегмент и той да бъде излъчван от маршрутизаторите на университета в глобалния BGP4+ обмен на маршрути като префикс 2a01:288:8000::/35. Подобно излъчване би изглеждало все едно префиксът 2a01:288:8000::/35 описва автономен адресен ресурс за краен потребител (без RIPE да са организирали още разпределянето на «ASSIGNED PI» IPv6 адресни ресурси).

За да изглежда това излъчване в BGP4+ напълно равносилно на това за автономен ресурс, трябваше да има поне два независими пътя на маршрутите. Единственият начин бе да убедим БИОМ да приемат излъчвания от нас префикс 2a01:288:8000::/35 и да го преизлъчват към всички свои доставчици (в това число и проекта GEANT2). Тук е мястото да се изкаже голяма благодарност на Ведрин Желязков и Станислав Спасов от БИОМ, които направиха това маршрутизиране възможно и го поддържаха до момента, в който СУ получи своя «ASSIGNED PI» ресурс. По този начин се осигури както адресен IPv6 ресурс за временно ползване, позволяващ изграждането на напълно функционална IPv6 свързаност, така и възможност за изучаване на възможностите за организиране на алтернативната маршрутизация от и към IPv6 Интернет.

Именно наличието на тази възможност способства за обучаването на мрежовите специалисти на Софийския университет в работата им с глобалната BGP4+ таблица, а така също и в начините за съставяне и конфигуриране на префиксни филтри в BGP. Постигна се ниво на натрупване на критична маса знания относно маршрутизацията на IPv6 трафик, което гарантираше минимален брой проблеми в момента, в който университетът получеше своето «ASSIGNED PI» автономно IPv6 адресно пространство. Нужно е да се спомене, че още тогава започна процесът на предоставяне на IPv6 свързаност за работните станции на служителите и студентите. През есента на 2007 г. над 50% от потребителите на мрежата на СУ вече имаха достъп до ресурси в Интернет достъпни чрез адресния протокол IPv6, а DNS сървърите на университета и тези за електронна поща започнаха да работят по механизма «dual-stack».

През 2009 г. членовете на RIPE постигнаха съгласие как да се осъществява алокирането на автономни IPv6 адресни пространства за «End User» потребители. След правилно попълнена и изпратена до RIPE заявка (с посредничеството на LIR Спектър Нет), на 11 февруари 2011 г., точно в 10:00 ч., RIPE NCC делегира на СУ „Св. Кл. Охридски" автономния IPv6 адресен ресурс 2001:67c:20d0::/47 със статус «ASSIGNED PI». По този начин СУ се нареди четвърти сред университетите в ЕС заявили и получили автономен IPv6 адресен ресурс. Според базата от данни на RIPE NCC (ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz) по-рано са заявили и получили своите „ASSIGNED PI" IPv6 адресни алокации Технически университет (ТУ) – Бърно (Чехия), на който е предоставен префикс /46, ТУ – Литва и Медицински университет – Виена (и двата с /48 алокации). За нуждите на алтернативната маршрутизация на база на ресурса 2001:67c:20d0::/47 са формирани два BGP рефикса – 2001:67c:20d0::/48 и 2001:67c:20d1::/48, които се анонсират през два независими канала за свързаност към Интернет (вж. оригиналната фигура, използвана за кандидатстването пред RIPE за обосновка на заявения адресен ресурс - Фиг.2).



Фиг.2 Оригиналната фигура, използвана за кандидатстването пред RIPE

4. Някои особености при свързването на IPv6 адресно пространство към Интернет

Вече бе споменато, че от критична важност за предоставянето на IPv6 свързаност е наличието на среда за пренос, която да може да осигури едновременен транспорт на IPv4 и IPv6 трафика в периода на прехода между IPv4 Интернет и IPv6 Интернет. Това бе описано като механизъм "dual-stack". Няма да е пресилено да се каже, че само чиста Ethernet свързаност между доставчика и клиентите му може да осигури работата на този механизъм при напречната свързаност между маршрутизаторите на доставчика и тези на клиента. Във всеки друг случай най-вероятно ще се наложи използването на тунелен протокол за транспорт на IPv6 пакетите през IPv4 базирана транспортна среда. Подобно транспортиране на IPv6 трафик в тунелна връзка може да доведе обаче до следните проблеми:

  • Изкуствено стесняване на преносния капацитет на пакети в IPv6 средата поради занижаване на стойността на MTU;
  • Невъзможност да се гарантира адекватно качеството на услугите (QoS) в IPv6 свързани с комуникация в реално време като VoIP и мултимедийни потоци (интерактивна телевизия и др).

Още от самото начало IPv6 свързаността на СУ с неговите доставчици бе базирана на Ethernet протокол и никога не са били използвани тунелни протоколи за транзит на IPv6 трафик.

Към настоящия момент повечето български доставчици на Интернет свързаност имат възможност да предоставят на свои клиенти "dual-stack" свързаност и предлагането на свързаност посредством тунел би следвало да се разглежда като слабо вероятна опция. Това твърдение се базира на следните факти. През периода 2008-2010 г. СУ започна изграждането на напречни връзки за обмен на локален (български) трафик с няколко доставчика, опериращи на територията на София, посредством MAN (Metropolitan Area Network или известна като градска среда за пренос): Еволинк, ITD Network, НЕТИССАТ, Цифрови системи и Нетера. Терминацията на IPv6 трафика по всяка една такава напречна връзка става посредством Ethernet базирани интерфейси и целият обмен на локален трафик следва предписанията за "dual-stack".

За да се стимулират Интернет доставчиците в предоставянето на IPv6 свързаност на своите клиенти, от 2007 г. насам в документацията за търговете по ЗОП за доставка на свързаност към Интернет за мрежата на СУ, са предявени следните изисквания към участниците в тръжната процедура: "да осигури поддръжка на стандартните протоколи за динамична маршрутизация и осигуряване на анонсирането на IPv4 и IPv6 префиксите с origin автономната система на мрежата на СУ (AS5421) ... да се осигури транспортиране на IPv6 трафик от и до мрежата на СУ... Гаранция за тази възможност е: Изпълнителят да има поне два доставчика на транзитна свързаност към световния Интернет (както по IPv4, така и IPv6), които да оперират на територията на САЩ и/или Европа." Това са доста строги, но изпълними изисквания. Въпреки изпълнимостта им обаче имаше случай на прекратяване на договор с фирма, спечелила подобен търг. Причината за това крайно решение бе, че в тръжната й документация бе описана невярна информация за наличие на IPv6 свързаност с изискуемите в заданието параметри.

5. Проблемът с „последната миля" - IPv6 свързаност за локалните потребители във вътрешната мрежа

Този проблем стои особено остро, защото без да бъде „заведена" IPv6 свързаността до нейните потенциални потребители и масовизирана, няма как да се създаде пълноценен IPv6 базиран Интернет. Решението на проблема за съжаление винаги е според конкретната специфичност на клиентската мрежа. Има и някои особености относно адресацията, които е важно да бъдат спазвани.

Ясно е, че статичното задаване на IPv6 адреси и маршрут по подразбиране върху клиентските станции в повечето случаи е неоправдано времеемко и не позволява лесното прекрояване на мрежовата топология, особено ако клиентът е подвижен спрямо отделните части на мрежата. Това може да се използва само в случаите на сървъри и работни станции с фиксирано местоположение в топологията. От друга страна, мрежовите администратори, които организират използваната от потребителите IPv6 свързаност, трябва да са запознати много добре с принципите на локалната IPv6 комуникация в Ethernet сегмент. Те следва да знаят, че локалната комуникация се осъществява с «local-link» адреси, които нямат нищо общо с публичните IPv6 адреси, които организацията е получила от своя LIR или RIPE, и че публичните IPv6 адреси се използват само за Интернет комуникация в рамките на протокола IPv6. Нужно е да могат да правят разлика между ARP и NDP (NDP — Neighbour Discovery Protocol) и да знаят защо NDP е част от IPv6.

В IPv6 има два механизма, по които дадена клиентска работна станция (или мобилно устройство) конфигурира при себе си автоматично IPv6 адрес и адрес на шлюз за мрежата: чрез протоколите NDP или DHCPv6. Трябва да се има предвид, че DHCPv6 използва компонент на NDP (научаването на шлюза на мрежа не е част от DHCPv6 протоколната комуникация между DHCPv6 клиента и сървъра, а е част от NDP). И NDP, и DHCPv6 могат изключително лесно да се реализират чрез софтуер с отворен код. За реализирането на NDP се използва пакетът radvd, а за DHCPv6 може да се използва ISC DHCP. Ако в мрежата на потребителите се използва само NDP, всеки мрежови стек на операционна система, който е конфигуриран да използва NDP, си самоназначава IPv6 префикс от /64 IPv6 префикс. Алгоритъмът на NDP за избора на IPv6 адрес гарантира вероятността за колизия (два хоста в локалната мрежа да изберат един и същи IPv6 адрес) да е почти нула и може да се счита да надежден. Шлюзът на мрежата пък се съобщава на потребителите от NDP сървъра, който работи върху маршрутизатора на локалната мрежа.

Какъв е опитът на специалистите от направление „Мрежи и комуникации" на УИЦ към СУ, който може да бъде споделен и евентуално да помогне на тези, които извършват бъдещи свързвания към IPv6 на потребителските работни станции в техните организации?

След като автономното IPv6 адресно пространство бъде получено, първо се решава как да се разпредели то между отделните подмрежи. В мрежата на СУ всеки факултет или самостоятелно звено притежава своя самостоятелна Ethernet базирана мрежа за вътрешни цели. За всяка такава мрежа е заделено по едно мрежово IPv6 адресно пространство с дължина на мрежовата маска от 64 бита (префикс /64). Тази размерност се определя от задължителните изисквания на протоколите NDP и DHCPv6 и е задължително да бъде спазена. Тя е и причината на «End User» да бъде предоставян такъв голям по размерност префикс като /48 — предполага се, че той ще има голям брой самостоятелни Ethernet базирани мрежи, в които ще използва NDP и DHCPv6 за хост конфигурация и следователно ще е нужен разход от по една /64 подмрежа за всяка Ethernet базирана мрежа с автоконфигурация на клиентите в нея. На шлюзовете на всяка подобна Ethernet базирана мрежа са инсталирани пакетите radvd и dhcp (ISC DHCP), които предоставят на клиентите възможност за автоконфигурация в зависимост от това кой от двата протоколи са избрали. Тенденцията е мобилните устройства да предпочитат използването на DHCPv6.

Сериозен проблем, касаещ автоматичната конфигурация на хостове в съвременните мрежи, е липсата на достатъчно евтини комутатори, които да регулират членството в IPv6 мултикастните групи. Например трябва да се гарантира, че няма как друг хост освен истинският шлюз на мрежата да съобщава на потребителските работни станции, че именно той е шлюзът, през който те да изпращат своите IPv6 пакети към Интернет.

6. Оптимизацията на IPv6 трафика във вътрешната мрежа

Както бе обяснено по-горе, всяка потребителска Ethernet мрежа следва да оперира с поне една мрежа /64. В случаите, в които мрежата на организацията е съставена от много на брой потребителски Ethernet мрежи, чиито маршрутизатори са свързани в централна опорна мрежова структура, изниква проблемът за динамичната вътрешна маршрутизация в тази структура. Затова трябва да се реши как даден маршрутизатор в опорната мрежа ще информира останалите кои точно /64 мрежи са достъпни през него (статичното задаване на маршрути не е изход за големи мрежи). Това води до избор на протокол за динамична маршрутизация на маршрути, описващи пътища до IPv6 адресни пространства. В момента най-често се използват три такива протокола: BGP4+, OSPFv3 и RIPng. Ако маршрутизаторите използват операционна система Linux, тези протоколи могат да се реализират с инсталирането на маршрутизиращ софтуер с отворен код като Quagga или Xorp.

Конкретно за нуждите на маршрутизацията на IPv6 трафика във вътрешната мрежа на СУ е избран протоколът BGP4+ и е реализирана схема на маршрутизация, известна като „маршрутен рефлектор" (route reflector), популярна за решаване на проблеми с мащабируемостта на обработката на маршрутната информация в протокола BGP4/4+ в т.нар. „Internet Exchanges". Отделно, за да се предотврати излъчването на много префикси във вътрешната BGP4+ таблица, на всеки факултет или самостоятелно звено се дава по един /60 префикс, което следва да му даде резерв от 16 на брой /64 префикси за бъдещо разширение на мрежата му. По този начин неговият маршрутизатор излъчва в BGP4+ таблицата, формирана в рефлектора, само един префикс /60, а не много префикси /64. Фиг. 3 по-долу представя идеята за действието на маршрутния рефлектор:



Фиг. 3 Маршрутният рефлектор

Всеки маршрутизатор от рефлекторната схема реализира по една BGP4+ сесия до т.нар. рефлекторни сървъри (два на брой, наименовани на фигурата като border-lozenets и border-rectorate). Когато участник в рефлекторната схема (рефлекторен клиент, всеки маркиран с «A») излъчи информация за нов маршрут към рефлекторните сървъри, последните я препредават на останалите рефлекторни клиенти. Така маршрутната информация се разпространява между всичките участници в рефлекторната схема, без да се налага изграждането на BGP4+ сесии между всеки два маршрутизатора. Освен това върху рефлекторните сървъри лесно се осъществява контрол над префиксното разпространение и налагането на предпазни филтри за префикси е еднозначно.

7. Често използвани мрежови услуги и IPv6 интеграцията им

7.1. DNS.

Ресурсният запис, описващ IPv6 адрес на хост се нарича „AAAA" (RFC1886). Всички съвременни сървърни DNS софтуери поддържат този тип ресурсни записи както в зоната на домейн, който обслужват, така и в рекурсивния процес на извличане на DNS информация, заявена от клиентите. Всеки съвременен сървърен софтуер за реализиране на DNS сървър поддържа механизма „dual-stack" за едновременна комуникация по IPv4 и IPv6 адресни протоколи, което улеснява миграцията на DNS услугата към новия адресен протокол.

Към момента основните DNS сървъри на СУ използват софтуера ISC BIND. В допълнение всички те работят в „dual-stack" и информацията за това е отбелязана в зоновите NS записи за домейна uni-sofia.bg и кореспондиращите им AAAA ресурсни записи:

NS ns.digsys.bg.

NS ns1.uni-sofia.bg.

NS ns2.uni-sofia.bg.

A 62.44.96.22

AAAA 2001:67c:20d0::22

...

ns1       A 62.44.96.140

            AAAA 2001:67c:20d0:ff::140

ns2       A 62.44.96.141

            AAAA 2001:67c:20d0:ff::141

Трябва да се отбележи, че единият от сървърите за имена, описани с NS ресурсни записи в зоната на домейна uni-sofia.bg, се намира извън мрежата на СУ, за да се покрие условието за отказоустойчивост (дори при отпадане на сървърите ns1.uni-sofia.bg и ns2.uni-sofia.bg, DNS информацията за домейна uni-sofia.bg да бъде достъпна в Интернет). Този сървър е ns.digsys.bg. Той също има IPv6 свързаност. По този начин DNS информацията за домейна uni-sofia.bg е достъпна изцяло в „dual-stack" режим и по двата адресни протокола.

За да бъде решена обратната задача в DNS (известна още като „reverse mapping"), за всяка IPv6 мрежа следва да се декларира и обслужва домейн ip6.arpa. В него се нанасят т.нар. PTR ресурсни записи, които имат за цел да дадат информация на заинтересованите потребители и приложения в Интернет какво име на хост съответства на даден IPv6 адрес. Тези PTR записи се съставят като се „обърне" записът на IPv6 адреса, запише се без съкращения, известни като „агрегации", и между всеки 2 шестнадесетични цифри се постави по една точка. Например, на IPv6 адреса 2001:67c:20d0::1 съответства ip6.arpa PTR запис:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.0.2.c.7.6.0.1.0.0.2.ip6.arpa

Делегирането на домейните ip6.arpa за /48 мрежите „ASSIGNED PI" става автоматично чрез създаване на обект в базата данни на RIPE (известна като RIPE DB). При създаването на обекта следва да се посочат сървърите за имена за домейна. След това специален автоматичен процес делегира описаната в обекта зона на домейн ip6.arpa в майчината ip6.arpa, която е под управлението на RIPE. За да се избегне задръстването с делегиращи поддомейнни записи на майчините зони за домейните ip6.arpa, оперирани от RIPE, не се позволява автоматичното делегиране на ip6.arpa домейни за мрежи с различна мрежова маска от /48 за „ASSIGNED PI" и /32 за мрежите на LIR („ASSIGNED PA"). Това означава, че всички дъщерни ip6.arpa зони се делегират йерархично през майчината зона, а не директно в зоната, оперирана от RIPE. Например, за мрежата със статус „ASSIGNED PI" 2001:67c:20d0::/48 е допустимо автоматичното делегиране на зоната на домейна 0.d.0.2.c.7.6.0.1.0.0.2.ip6.arpa чрез обект в базата данни на RIPE (RIPE DB). Но за мрежата 2001:67c:20d0:2:/60 делегирането на домейна ip6.arpa следва да се извърши в 0.d.0.2.c.7.6.0.1.0.0.2.ip6.arpa, а не през RIPE DB.

7.2. Електронна поща.

Без значението от версията на използвания за преноса на електронната поща IP протокол, услугата "електронна поща" условно се състои от три компонента: MTA (Mail Transport Agent), MDA (Mail Delivery Agent) и MUA (Mail User Agent). Допълнително към нея се прибавят компоненти за антиспам и антивирусна защита. Към момента всички изброени компоненти са използваеми за миграцията по схемата "dual-stack" и това опитно е проверено в мрежата на СУ.

7.2.1. MTA. Всички (без изключение) популярни и актуални софтуерни продукти с отворен код за реализиране на MTA компонентата са напълно готови за използването на IPv6 "чисто" или в "dual-stck" (Sendmil, Postfix, Exim, Courier MTA и др.). Те поддържат специфични конфигурационни опции на база конкретен IPv6 адрес или мрежа (адрес за приемане на електронната поща, адрес за изпращане и филтри). В мрежата на СУ за MTA се използва главно Sendmail (с LDAP интеграция).

7.2.2. MDA. И тук всички софтуерни проекти с отворен код поддържат IPv6 и удовлетворяват изискванията на механизма "dual-stack", като е без значение дали пощенския сървър поддържа само протокола POP3 или само IMAP (или и двата едновременно). В мрежата на СУ се използва предимно протоколът IMAP, а MDA сървърния софтуер е обикновено Cyrus IMAPD, Zimbra или Dovecot.

7.2.3. MUA. И в този случай наличният софтуер е напълно подходящ за осъществяване на миграцията от IPv4 към IPv6 по механизма "dual-stack". Повечето съвременни (като дизайн) електронни пощенски клиенти предоставят поддръжка на IPv4 и IPv6 напълно прозрачно за клиента. Без значение дали става дума за клиенти с отворен код като Thunderbird, Kmail, уеб базирания клиент Squirrelmail или за мобилните им аналози. Всички те могат да използват пощенските сървъри на СУ и по двата адресни протокола, напълно прозрачно за потребителя, ако работната му станция или мобилното му устройство имат IPv6 свързаност към Интернет.

7.3. WWW

Уеб сървърът на СУ (www.uni-sofia.bg) и сървъри на някои факултети функционират по механизъм "dual-stack" и са достъпни както по IPv4, така и по IPv6. За целта се използва продуктът с отворен код Apache, който реализира HTTP сървър и позволява предоставяне на съдържание по протокола HTTP и по двата адресни протокола, в зависимост по кой от тях е получена клиентската заявка. За да може клиентът да заявява предоставяне на съдържание по IPv6 от сървъра, следва името на хост, който ще присъства в HTTP протоколната заявка, да има AAAA ресурсен запис в съответната зона на домейн. Например, за www.uni-sofia.bg и uni-sofia.bg са направени следните записи в зоната на домейна uni-sofia.bg

@ AAAA 2001:67c:20d0::22

A 62.44.96.22

www AAAA 2001:67c:20d0::22

A 62.44.96.22

Когато един HTTP клиент запита за IP адреса на www.uni-sofia.bg или uni-sofia.bg, системата за имена DNS ще му даде както отговор за IPv4 адреса, така и за IPv6. Ако клиентът има текуща работеща IPv6 свързаност, той ще достъпи www.uni-sofia.bg или uni-sofia.bg чрез свързване до съответния IPv6 адрес.

Не съществува принципен или практически проблем за реализирането на HTTP виртуален хостинг базиран на име на хост или IPv4 и IPv6 адрес. Не само Apache, но и други сървърни софтуери като LigHTTPD са напълно готови да посрещнат нуждата от такъв хостинг.

8. Заключение

Описаните тук практики и резултати показват един възможен начин за преминаване към адресния протокол IPv6 чрез междинното използване на «dual-stack». Този начин е подходящ преди всичко за академични организации с ограничен бюджет, но с добре обучени мрежови специалисти. Най-вероятно тези практики са трудно приложими за организации, които се занимават с доставка на Интернет свързаност или такива, които разчитат за маршрутизацията си на специализиран хардуер. Със сигурност обаче описаното може да даде идеи и насоки, които биха спестили време и разходи на труд и материални средства в процеса на прехода от IPv4 към IPv6.

Важно предимство на описаните решения е, че те осигуряват прозрачни спрямо избора на адресен протокол услуги и свързаност, предоставящи висока производителност на минимална цена. Проведените тестове (Фиг. 4) сочат 100% подготвеност на мрежата на СУ за обслужване на трафик и по двата протокола - IPv4 и IPv6 (test-ipv6).



Фиг. 4 Проведените тестове сочат 100% подготвеност на мрежата.

Използваните софтуерни продукти с отворен код са предпоставка за въвеждането с минимални разходи и на други иновативни решения като удостоверяване на BGP сесиите между съседни маршрутизатори чрез IPSec AH протокол, цифрово подписване на DNS записи (DNSSEC), резервираност на DNS услугата чрез йерархична Anycast схема и др.

Автори на публикацията: Веселин Колев, Николай Николов, Стефан Димитров, Христо Драголов, Радослав Бучакчиев, Георги Найденов, Мариана Петкова, Владислав Георгиев, Иван Йорданов

Литературни източници

  • Колев, 2008, Настройки на пощенските концентратори на мрежата на СУ "Св. Климент Охридски" за работа с IPv6, http://www.vesselin.org/papers/xhtml/sendmail-ipv6.html
  • Apache, http://httpd.apache.org/docs/trunk/
  • BIND, http://www.isc.org/software/bind
  • CentOS, http://www.centos.org/
  • Quagga, http://www.quagga.net/
  • radvd, http://en.wikipedia.org/wiki/Radvd
  • RFCs, http://www.ietf.org/rfc/
  • ripe-509, http://www.ripe.net/ripe/docs/ripe-509
  • ripe-552, http://www.ripe.net/ripe/docs/ripe-552
  • test-ipv6, http://test-ipv6.com/ 
(07.03.2013)

КОМЕНТАРИ

 
  
15:20, 25 март 2013 # 1
NO AVATAR
Аз rel="nofollow" съм един от авторите на статията. Откакто статията е публикувана (вижда се и колко прочита има), доста хора ми се обадиха да ни поздравят за нея и да ни кажат колко им е помогнало написаното. Вместо някой от ръководството на Софийския Университет да похвали авторите за труда им, днес няколко от тях са извикани на среща и са били обвинявани в административно нарушение. В какво се състояло то - не били съгласували статията с новоназначеното ръководство на Университетския изчислителен център и функционалния ректор на СУ Димитър Биров. Забележете, в академична общност не се изисква разрешение да се публикува статия. Очевидно в СУ това не се знае (уместно е да се попита това университет ли е). Отправяно е и обвинение, че с публикуването на IPv6 адресното пространство на Университета се нарушавала сигурността! Представете си какъв е техническия капацитет на обвиняващия и си представете неговото уникално технологично бездарие, след като всеки желаещ може да научи какво е адресното пространство на Университета чрез запитване на RIPE DB. Нито ръководството на СУ, нито т.нар. функционален ректор Д. Биров имат каквито и да са познания в IPv6! А що се касае до сигурност, нужно е българското интернет пространство да знае, че въпросния функционален ректор Д. Биров съхранява служебна и поверителна информация на Университета в пощенска кутия в GMail, което показва, че не само не разбира от сигурност, но и е главен фактор за несигурност в този университет.
 
  
17:13, 25 март 2013 # 2
NO AVATAR
Ед rel="nofollow" на ограмотителна презентация за "секюрити гурото" Д. Биров:

http://vesselin.org/presentations/files/present-openfest-2009.pdf

с пожелание да стане ако може малко грамотен.
 
  
08:16, 09 март 2016 # 3
NO AVATAR
Hi to everybody, here everyone is sharing such knowledge, so it’s fastidious to see this site, and I used to visit this blog daily.virginia online payday loan lenders
 
  
08:51, 09 март 2016 # 4
NO AVATAR
Hi to all, the blog has really the dreadful information I really enjoyed a lot.life onsura ce
 
  
04:58, 18 август 2018 # 5
NO AVATAR
20180818lck

van cleef arpels jewelry


ray ban


canada goose outlet store


supreme t shirts


cleveland cavaliers jerseys


nike roshe run


prada bags


true religion outlet uk


cheap ugg boots


calvin klein jeans


michael?kors?handbags


broncos jerseys


kobe 9 elite


kobe shoes


gucci outlet store


moncler coats


isabel marant outlet


kate spade outlet online


true religion uk


new balance outlet


fitflops sale clearance


uggs outlet


michael kors handbags


michael?kors?outlet?online


nike air huarache


mulberry handbags


prada sunglasses for women


uggs outlet


mbt outlet


pandora charms sale clearance


cheap oakley sunglasses


air jordan shoes


puma shoes


g-star jeans


cheap jordans free shipping


canada goose outlet store


kate spade handbags


adidas outlet online


christian louboutin shoes


air jordan shoes


coach outlet online


nfl jerseys


michael kors outlet online


ysl outlet online


canada goose jackets


tory burch outlet online


michael kors outlet online


kyrie 4


cheap jerseys wholesale


michael kors outlet online


adidas wings shoes


true religion outlet


canada goose outlet


moncler outlet store


nhl jerseys


true religion outlet


gucci outlet online


pandora charms sale clearance


coach factory outlet


ralph lauren uk


prada outlet online


polo ralph lauren outlet


longchamp handbags


snapbacks wholesale


cheap nhl jerseys


mbt


malone souliers


cheap soccer jerseys


air max shoes


ralph lauren shirts


gentle monster sunglasses


cheap jordan shoes


supreme t shirts


longchamp handbags


canada goose jackets


hermes birkin bag


uggs outlet


soccer cleats


canada goose


adidas outlet online


fila sneakers


coach outlet online


nike uk store


ralph lauren outlet


ugg outlet


coach outlet


cazal outlet


red bottoms


jordan retro


fitflops


uggs outlet


true religion outlet store


burberry outlet online


air jordan shoes


pandora outlet


cheap jordans


hermes outlet store


swarovski outlet store


ralph lauren outlet


ugg boots


polo ralph lauren


fred perry polo


polo ralph lauren shirts


michael kors outlet clearance


michael kors factory outlet


nike store uk


canada goose outlet


chopard jewelry


toms outlet


stussy hoodie


balmain jeans


mcm backpacks


cheap ugg boots


burberry canada


chrome hearts online store


mulberry handbags sale


air max 90


michael kors outlet online


kate spade


pandora charms sale clearance


nike outlet online


fitflops


chloe sunglassess


michael kors outlet


coach outlet


cheap jordan shoes


ugg outlet


michael kors outlet online


canada goose outlet store


longchamp solde


coach outlet


pandora charms


manolo blahnik outlet


canada goose coats


wellensteyn outlet


nike air huarache


cheap ugg boots


kate spade sale


kevin durant shoes


kate spade outlet online


polo ralph lauren shirts


air jordan shoes


ugg outlet


christian louboutin outlet


canada goose outlet store


pandora charms sale clearance


ralph lauren outlet


michael kors outlet online


michael kors handbags


michael kors outlet online


swarovski uk


ralph lauren polo


air max 90


true religion outlet


49ers jersey


converse shoes sale


uggs outlet


freshjive clothing


coach outlet online


pandora charms sale clearance


coach factory store


furla handbags


canada goose outlet


oakley sunglasses uk


air force 1 shoes


coach factory outlet


moncler jackets


air max 90


cheap oakley sunglasses


coach outlet clearance


air max shoes


longchamp outlet store


kd shoes


givenchy handbags


jordan 4


coach outlet online


ferragamo shoes


uggs outlet


ralph lauren outlet


nike shoes


uggs outlet


michael kors outlet online


air max 90


alexander mcqueen shoes


canada goose jackets outlet


longchamp pas cher


mont blanc outlet


tory burch outlet online


adidas yeezy boost


jordan shoes


kate spade sale


supreme clothing uk


off white clothing


ray ban sunglasses outlet


links of london jewellery


mac cosmetics


huf clothing


lacoste shirts


ugg outlet


christian louboutin shoes


moncler outlet online


tory burch outlet stores


cheap jordans


canada goose outlet online


miu miu shoes


canada goose outlet store


canada goose jackets


ecco outlet


michael kors outlet clearance


nobis jackets


jordan 4


cheap ray ban sunglasses


uggs outlet


cheap ray ban sunglasses


christian louboutin shoes


coach outlet online


swarovski jewelry


michael kors outlet


ray ban sunglasses outlet


michael kors outlet online


cheap football shirts


jerseys from china


toms outlet


ugg boots clearance


polo ralph lauren


michael kors outlet online


brequet wathes


ugg boots clearance


nike shoes outlet


oakley sunglasses wholesale


coach factory outlet


cheap jordan shoes


air max 2015


canada goose outlet store


uggs outlet


kd 10 elite


michael kors outlet online


jordan shoes


champion clothing


jimmy choo sunglasses


fitflops shoes


christian louboutin shoes


tory burch outlet online


nike shoes outlet


air jordan shoes


yeezy boost 350


kevin durant jerseys


kate spade handbags


coach outlet


fossil watches


kate spade handbags


louboutin shoes


cheap nba jerseys


dsquared2 jeans


canada goose jackets outlet


cheap oakley sunglasses


asics running shoes


jordan 3


bcbg dresses


polo ralph lauren outlet


polo ralph lauren shirts


tods outlet online


cheap ray ban sunglasses


off-white clothing


uggs outlet


true religion jeans


canada goose outlet store


cheap jordans


coach outlet online


cheap jordan shoes


canada goose outlet


guess factory


michael kors outlet online


pandora charms


longchamp handbags sale


michael kors outlet


true religion outlet


canada goose outlet store


pandora jewelry


cheap nba jerseys


christian louboutin shoes


james harden jerseys


hermes outlet store


uggs outlet


canada goose jackets


ralph lauren polo


ferragamo shoes


fitflops sale clearance


christian louboutin shoes


nike air max


pandora charms sale clearance


cheap ray ban sunglasses


colts jerseys


kate spade sale


burberry outlet store


michael kors outlet online


cheap ray ban sunglasses


true religion jeans


golden state warriors


michael kors outlet online


20180818lck
Трябва да сте регистриран потребител, за да коментирате статията
"IPv6 свързаност за Софийския университет "Св. Климент Охридски""



    

© Ай Си Ти Медиа ЕООД 1997 - 2019 съгласно Oбщи условия за ползване | Декларация за поверителност | Политика за бисквитки