Версия 1.2.0, 27 юли 2008
Веселин Колев, Георги Найденов, Стефан Димитров - Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Трудности при заявяване на IPv6 адресно пространство за краен потребител
Организиране на транзита на IPv6 трафика от и към автономната система на Университета (AS5421)
Някои затруднения при излъчване на префикса 2a01:288:8000::/35
Политика на раздаване на IPv6 адреси на самостоятелните звена в Университета
Конфигуриране на Quagga за създаване на OSPF6 area 62.44.127.0
Конфигуриране на Quagga за създаване на BGP4+ сесии с граничните маршрутзатори на AS5421
Делегиране на ip6.arpa домейни за адресното мрежово пространство 2a01:288:8000::/35
DNSSEC проблеми с 8.8.8.2.0.1.0.a.2.ip6.arpa и 9.8.8.2.0.1.0.a.2.ip6.arpa и план за решаването им
Колаборация с Register.BG за въвеждане на "glue AAAA" делегиране за домейни в TLD BG
Използвана операционна система и софтуер за управление на динамичната маршрутизация
Този документ има статус на техническо описание на решение без претенции за пълнота в описанието. Авторите публикуват този материал в името на обществената полза и с цел популяризиране на използването на IPv6.
Заявяването на IPv6 адресно пространство за краен потребител към настоящия момент не е тривиална задача, поне в региона на действие на RIR RIPE. Причината е, че към момента регионалния интернет регистър (RIR) RIPE приема заявки за алокиране на IPv6 мрежови адресни пространства само и единствено от LIR (локални интернет регистри). Тази политика на алокиране е описана в RIR документа "RIPE-421", който е публично достъпен на адрес:
http://www.ripe.net/ripe/docs/ripe-421.html
От съдържанието на документа става ясно, че за да получи IPv6 алокация директно от RIR RIPE, субектът Софийски Университет следва да бъде LIR и да се наеме с раздаването на IPv6 адресно пространство с дължина на мрежовата маса от 32 бита. Придобиването на LIR статус от страна на Университета е финансово неоправдано, а освен това не са налице функции на LIR, който биха били поети, ако бъде получен такъв статус. От друга страна адресно пространство с дължина на мрежовата маска от 32 бита е прекалено огромно и не си заслужава да бъде "погребвано" в организация, която никога няма да може да го използва и на 1%. Да не говорим за изискването, според което в ролята си на LIR Университета би следвало да се ангажира да раздаде поне 200 IPv6 адресни субалокации с дължина на мрежовата маска 48 бита за свои клиенти (!).
Причината, поради която RIR RIPE не извършва директна алокация на IPv6 пространства за крайни потребители (както това е в IPv4), е че няма все още общоприета регионална политика за извършване на "PI" алокации в IPv6. Към момента обаче има предложение за документ, съгласно който в бъдеще подобно PI алокиране би било реално:
http://ripe.net/ripe/policies/proposals/2006-02.html
Към момента на написването на тази документация предложението все още не е получило статус на официален документ на RIR RIPE.
От написаното по-горе следва, че за момента няма адекватна и обслужваща нуждите на Университета процедура, чрез която да се алокира IPv6 адресно пространство.
В предишния параграф са описани трудностите относно получаването на IPv6 пространство за краен потребител. Тези трудности се засилват от факта, че българските доставчици на интернет свързаност, които изпълняват в по-голямата си част ролята на LIR, все още не са запознати с IPv6 и нямат свързаност по този адресен протокол.
В момента, в който техническия екип на Университета започна търсенето на начин за алокиране на IPv6 адресно пространство, в България реално имаше само един LIR субект, който имаше IPv6 свързаност и беше в състояние да осигури адресен сегмент за нуждите на Софийския Университет и съответно транзит на IPv6 трафик. Това бе Академичната мрежа (NREN).
Следователно най-лесния вариант би бил Академичната мрежа да даде на Софийския Университет за използване част от своя /32 сегмент. Реално обаче това не би донесло никакви ползи за българското интернет пространство. Причината е, че подобно алокиране не кара комерсиалните доставчици на интернет свързаност у нас да се променят и въвеждат нови технологии, каквато е IPv6. Т.е. реално технологията не се отваря към масовост, а остава затворена в академични кръгове, което не носи нужната обществена полза. Именно затова бе избран колаборативен подход с комерсиален доставчик на свързаност, който да има статус на LIR и да има желанието да внедри IPv6 при себе си, а оттам и да предоставя свързаност по този адресен протокол и за своите клиенти. Именно по този начин би станало разпространението на технологията и само по този начин би имало обогатяване на пазара на интернет услуги, което ползва крайния потребител.
След разговори между техническите лица на Университета и LIR "Spectrum NET", последния реши да изиска от RIR RIPE полагащия му се /32 адресен IPv6 сегмент, да настрои мрежовото си оборудване за извършване на транзит на IPv6 трафик и да алокира адресно подпространство за нуждите на Софийския Университет "Св. Климент Охридски". По този начин "Spectrum NET" стана първият комерсиален доставчик на IPv6 свързаност и транзит в България и единствения комерсиален LIR, който може да заделя за клиенти IPv6 адресни сегменти от своя /32 адресен сегмент. Това е и пример, при който академична общност се явява катализатор за възприемането на една сравнително нова технология за масова употреба.
Полученият от "Spectrum NET" адресен блок е:
2a01:288::/32
Статусът на този блок е ALLOCATED-BY-RIR. От него за нуждите на Софийския Университет "Св. Климент Охридски" е заделен адресния блок:
2a01:288:8000::/35
който има статус ALLOCATED-BY-LIR.
Транзитирането на IPv6 трафик от и към граничните маршрутизатори на AS5421 става чрез три BGP4+ сесии. Две от тези сесии са с граничен маршрутизатор на AS6802 (NREN), а едната е с граничен маршрутизатор на AS8717 (Spectrum NET). Граничният маршрутизатор border-secondary.uni-sofia.bg има само една BGP4+ сесия, установена с граничния маршрутизатор на AS6802, докато border-main.uni-sofia.bg има установени две BGP4+ сесии: едната с граничния маршрутизатор на AS6802 и една с граничния маршрутизатор на AS8717.
Установените BGP4+ сесии за транзит на IPv6 трафик са изобразени схематично на Фигура 1:
Фигура 1: Установени BGP4+ транзитни сесии между маршрутизаторите на AS5421 и тези на AS6802 u AS8717 (натисни възху изображението за увеличение)
Бе постигнато съгласие с техническите лица на Академичната мрежа за транзит на IPv6 трафик през техните маршрутизатори от и към Интернет през преносната транзитна среда на Европейската изследователска мрежа GEANT2. Отделно бе постигнато съгласие за транзит на IPv6 трафик през автономната система на Spectrum NET, по преносна среда MAN, която Софийския Университет е наел от оператора Евротур.
Граничните маршрутизатори на AS5421 са BGP първоизточник (originator) на IPv6 префикса 2a01:288:8000::/35 в общата BGP интернет таблица. За да може да бъде излъчван този префикс през граничните маршрутизатори на AS6802, а оттам и към тези на Европейската изследователска мрежа (GEANT2), откъдето да се излъчи към останалите гранични маршрутизатори в Интернет, се изискваше да бъде заявена промяна на филтрите на граничните маршрутизатори на AS6802 и AS20965. Това бе направено от колегите по техническа поддръжка на Академичната мрежа.
Допълнително бе постигнато съгласие Spectrum NET да излъчват без агрегация префикса на Университета 2a01:288:8000::/35, който получават от граничните маршрутизатори на AS5421. Принципно Spectrum NET следва да агрегират префикса 2a01:288:8000::/35 до 2а01:288::/32 поради статуса на тяхното адресно пространство, но доколкото случая с този префикс е особен (излъчване на 2а01:288:8000::/35 през два транзитни доставчика), то агрегация не се налага. Ако би била наложена подобна агрегация, това би означавало входящия трафик към адресното IPv6 пространство на Университета да преминава единствено през връзката с Академичната мрежа. Причината за подобно поведение на входящия трафик е много проста. Ако Spectrum NET излъчват само 2a01:288::/32, а през Академичната мрежа се излъчва 2a01:288:8000::/35, то вторият префикс е по-специфичен (точен) и би следвало трафика към адресите в него да преминава по пътя на излъчването му (т.е. през GEANT2 и Академичната мрежа).
Ако трябва да се сумира процеса на излъчване:
излъчване през Spectrum NET:
2a01:288::/32 2a01:288:8000::/35
излъчване през Академичната мрежа и GEANT2:
2a01:288:8000::/35
След обстойна проверка се установи, че някои гранични маршрутизатори не приемат префикса 2a01:288:8000::/35, а приемат само агрегирания префикс 2a01:288::/32. Примери за такива са граничните маршрутизатори на автономна система 1280, оперирана от Internet Systems Consortium (ISC). След контакти с техническите им лица филтрите им за префикси бяха коригирани, но самото наличие на такава филтрация поставя въпроса доколко изобщо операторите на маршрутизатори в Интернет са склонни да допускат префикси с дължина на мрежовата маска различна от /32 и /48. Нужно е да се каже, че подобни проблеми има и с граничните маршрутизатори на автономна система 14277.
Съгласно документите на RIR RIPE, които са възприети и от другите регионални интернет регистри, би следвало най-малкия префикс в IPv6, който следва да не се филтрира да е с дължина на мрежовата маска 48 бита - толкова колкото е минималната алокация извършвана от LIR за краен клиент и дължината на мрежовата маска за директна алокация на IPv6 адресно пространство за краен потребител (когато предложението за последното бъде прието). Следователно филтрирането на префикси с дължина на мрежовата маска между 32 и 48 бита не е добра практика и не е установена с никакви съглашателства и споразумения между общността. Нещо повече, подобна филтрация може да доведе до концентриране на транзитен трафик в някои точки, а това да доведе до влошаване на услугата по транзит. По-лошият резултат би бил ограничена видимост на адресни пространства в IPv6. Някои от филтриращите обаче се позовават на това, че след като още няма документ за директна алокация за краен потрбител на база префикс с дължина /48, то би следвало да се допускат само /32 префиксите. Това е погрешно. Първо някои RIR вече имат политика за PI алокации (напр. AfriNIC) и вече извършват директни /48 алокации и по-големи (напр. /47, /46). Второ, очаква се съвсем скоро RIR RIPE също да започне да извършва такива. Следователно не бива да има филтри в описанията на BGP4+ сесиите за транзит, които да отхвърлят приемането на префикси с дължини на мрежовата маска между 32 и 48 бита.
Всяко самостоятелно звено в рамките на Университета може да заяви IPv6 адресно пространство чрез молба до Университетския изчислителен център. Към момента всяка заявка се удовлетворява (при наличието на техническата възможност за транспорт на IPv6 трафик) чрез предоставяне на заявителя на адресно пространство с дължина на мрежовата маска 48 бита. Алокирането на сегмент за дадено звено може да стане и по подразбиране за звената, в които се поставят нови маршрутизатори, които имат излаз до бекбон мрежата на Университета. Целта е до 2009 година всички самостоятелни звена в Софийския Университет да използват IPv6.
Към момента на написване на документацията, всички самостоятелни звена в кампус "Лозенец" разполагат с IPv6 адресни пространства, част от префикса 2а01:288:8000::/35. Ето техния списък, заедно с алокираното пространство:
Университетски изчислителен център (УИЦ):
2a01:288:8003::/48
Факултет по математика и информатика (ФМИ):
2a01:288:8002::/48
Физически факултет (ФзФ):
2a01:288:8005::/48
Химически факултет (ХФ):
2a01:288:8004::/48
Лаборатория по инженерна химична физика (ЛИХФ):
2a01:288:8001::/48
Във всички тези звена раздаването на адресите във вътрешните им мрежи се извършва чрез Radvd съгласно RFC2461. Това означава, че не е нужно потребителят да извършва никакви конкретни настройки на адреси, адресни маски и шлюзове. Такива му се назначават автоматично. Има ограничения. По подразбиране настройките на мрежовите устроства на Windows XP са такива, че не се извършва автоматична настройка на IPv6 адресация. Тя следва да се активира. Такива проблеми няма с Windows Vista, където настройката е активирана по подразбиране. Всички системи базирани на Linux или BSD дистрибуции следва да имат активирана IPv6 адресация по подразбиране.
В рамките на Университетската мрежа се използва резервирано за служебни цели IPv6 адресно пространство. Адресите в рамките на това пространство се предоставят на мрежовите устройства за управление на трафика или сървърите за поддръжка на основните услуги.
Цялото адресно пространство
2a01:288:8000::/48
е резервирано за служебни цели, като в момента има следните подалокации:
2a01:288:8000::/96
Това е адресното пространство за маршрутизаторите в бекбон мрежата на Софийския Университет.
2a01:288:8000:aaaa::/96
Това адресно пространство се използва за основните сървъри предоставящи мрежови услуги с общоуниверситетско значение.
Разпространението на информацията засягаща маршрутизацията от граничните маршрутизатори на AS5421 към маршрутизаторите на самостоятелните звена става чрез BGP4+ сесии. Всеки от маршрутизаторите на самостоятелните звена поддържа по една BGP4+ сесия към всеки един от граничните маршрутизатори на AS5421. Необходимостта от поддържането на две BGP4+ сесии е резервираност при отпадане на единия от маршрутизаторите. Доколкото мрежата на Софийския Университета следва да прилага добрите практики относно динамичната маршрутизация, то не би следвало да има статична маршрутизация, особено такава по подразбиране. Именно затова целия процес на маршрутизиране дори вътре в мрежата на Софиийския Университет е основан на протокола BGP.
Всеки от маршрутизаторите на самостоятелните звена получава по BGP4+ сесиите пълните BGP таблици на граничните маршрутизатори на AS5421 формирани от информацията получена от граничните маршрутизатори на транзитните автономни системи (за случая това са автономни системи 6802 и 8717). За да могат обаче маршрутизаторите на самостоятелните звена да извършват маршрутизация на изходящия трафик в условията на iBGP, следва да разполагат с допълнителна информация за реализирането на "next hop" през транзитните автономни системи. Тук на помощ идва протокола OSPFv3 и по-специално нарочно поддържаната за целта OSPF6 area 62.44.127.0.
OSPF6 area 62.44.127.0 служи за решаване на рекурсивната задача за изходящия трафик на база подадените в BGP4+ сесията маршрути. Ето и нейно илюстративно описание (в облака са посочени маршрутите, които тя има за цел да пропагандира):
Фигура 2. Структуриране на OSPF6 area 62.44.127.0 (натисни върху изображението за увеличение)
OSPF6 area 62.44.127.0 дава посока за "next hop", тъй като всеки маршрутизатор в бекбон мрежата на Софийския Университет получава чрез BGP4+ сесиите пътища, чиито "next hop" е IP адреса на граничния маршрутизатор на автономната система, подала информация за маршрута, но последния не е в един етернет сегмент с маршрутизатора в бекбона. Ето пример как чрез OSPF6 area се решава рекурсивно задачата за маршрутизацията на изходящия трафик. Маршрутизатор от бекбон мрежата на Университета е получил следната информация за маршрут до 2001:610::/32:
6802 20965 1103, (aggregated by 1103 145.145.127.2)
2001:4b58:acad:252::2d from 2a01:288:8000::1 (62.44.127.1)
(fe80::20e:cff:fe07:571c)
Origin IGP, localpref 100, valid, internal, atomic-aggregate, best
Last update: Mon Jul 14 16:48:30 2008
Следователно за да се намери маршрута до адрес от сегмента 2001:610::/32, например 2001:610:240:11::c100:1319, следва пакета да се изпрати към "next hop" адрес 2001:4b58:acad:252::2d. Ако се разгледа обаче схемата на Фигура 2 ще се установи, че маршрутизаторите от бекбон мрежата не са в един и същи етернет сегмент с маршрутизатора с адрес 2001:4b58:acad:252::2d и няма условия за реализиране на описания "next hop". Следователно трябва да се извърши рекурсивно пресмятане към кой от граничните маршрутизатори на Университета да се изпрати пакета за хоста с IPv6 адрес 2001:610:240:11::c100:1319. Тази рекурсивна задача се решава с помощта на информацията от OSPFv3 протокола, подавана в OSPF6 area 62.44.127.0. Ако се разгледат маршрутите, оповестени в нея, става ясно как да се реши рекурсивната задача. На Фигура 2 се вижда, че сегмента 2001:4b58:acad:252::2c/126, в който се намира адреса 2001:4b58:acad:252::2d на интересуващия ни маршрутизатор, е достъпен през граничния маршрутизатор с IPv6 адрес 2a01:288:8000::1. Следователно решението на рекурсивната задача за изпращане на пакет до хост с IPv6 2001:610:240:11::c100:1319, е да се изпрати пакета към маршрутизатора с IPv6 адрес 2a01:288:8000::1, който от своя страна да продължи пакетния пренос към следващия маршрутизатор и т.н., докато пакета достигне назначението си.
Отделно, с цел икономична и гъвкава вътрешна за Университетската мрежа маршрутизация, се използва BGP4+ рефлекторна схема. На Фигура 3 е представена илюстрация на рефлекторната схема:
Фигура 3. BGP4+ рефлекторна схема за вътрешна маршрутизация (натисни върху изображението за увеличение).
Схемата на рефлектора отчита участниците към момента на написване на този документ, което означава, че Фигура 3 може да бъде неактуална в бъдещ момент от време.
Целта на рефлекторната схема е да даде най-кратък път при маршрутизация в рамките на една автономна система от маршрутизатори. За целта всеки от тях се явява първоизточник (originator) на мрежата, за която е шлюз. Той излъчва префикса за тази мрежа към двата гранични маршрутизатора на AS5421, които в случая са точно в ролята на "отражатели" ("рефлектори"). Те подават префикса на другите свързани към тях маршрутизатори на AS5421, които в случая са маршрутизаторите на самостоятелни звена свързани в бекбон мрежата. Доколкото "next hop" параметъра в BGP префикса се намира в същия етернет сегмент, то обмена на трафик между мрежите зад маршрутизаторите в бекбон мрежата, става директно, без да се минава през "отражателите", в случая граничните маршрутизатори. Това облекчава изключително трафика, защото не натоварва граничните маршрутизатори с излишна обработка на локален трафик. Ето пример за действието на рефлекторната схема в BGP4+. Нека маршрутизаторите 2a01:288:8000::15 и 2a01:288:8000::19 решават задачата за пренос на пакети от хост в мрежа 2a01:288:8001::/48, за която шлюз е 2a01:288:8000::19, до хост в мрежа 2a01:288:8002::/48, за която шлюза е 2a01:288:8000::15, и в обратната посока. Маршрутизаторът 2a01:288:8000::19 е излъчил в BGP4+ сесиите си към двата "отражателя" (съответно с адреси 2a01:288:8000::1 и 2a01:288:8000::a) информацията, че мрежата 2a01:288:8001::/48 е достъпна през него. Тази информация автоматично се предава от "отражателите" към маршрутизатора 2a01:288:8000::15. По този начин 2a01:288:8000::15 знае, че мрежата 2a01:288:8001::/48 е достъпна "next hop" през маршрутизатора 2a01:288:8000::19. Маршрутизаторът 2a01:288:8000::15 от своя страна е излъчил в BGP4+ сесиите си към двата "отражателя" информацията, че мрежата 2a01:288:8002::/48 е достъпна през него. Тази информация автоматично се предава от "отражателите" към маршрутизатора 2a01:288:8000::19. По този начин 2a01:288:8000::19 знае, че мрежата 2a01:288:8002::/48 е достъпна "next hop" през маршрутизатора 2a01:288:8000::15. В края на този обмен маршрутизаторите имат следната информация:
в маршрутната таблица на 2a01:288:8000::15:
2a01:288:8001::/48 via 2a01:288:8000::19
в маршрутната таблица на 2a01:288:8000::19:
2a01:288:8002::/48 via 2a01:288:8000::15
Следователно обменът на пакети между хостовете от мрежите 2a01:288:8001::/48 и 2a01:288:8002::/48 ще става директно между маршрутизаторите, които са шлюзове за тези мрежи и няма да се преминава през "отражателите". Най-важното в случая е, че това става без да има директни BGP4+ сесии между маршрутизаторите, които са шлюзове за разглежданите две мрежи. Този факт е в основната на оптмизацията на локалния трафик чрез рефлекторна схема.
По-долу е дадена конфигурацията на демона ospf6d (намираща се във файла /etc/quagga/ospf6d.conf), чрез който реализира OSPFv3 върху маршрутизаторите в AS5421. Конфигурацията е дадена отделно за всеки от двата гранични маршрутизатора и за един от маршрутизаторите на самостоятелни звена, свързан в бекбона. Показани са филтрите за излючване на префикси в OSPF6 area 62.44.127.0. Филтрирането става с "route-map" структура наименована REDISTRIBUTE_CONNECTED_IPV6. Целта й е да разрешава излъчване във въпросната area само на нужната информация за решаване на рекурсивните задачи в BGP и нищо повече. По подразбиране маршрутизаторите на самостоятелни звена свързани към бекбон мрежата, не би трябвало да излъчват информация в OSPF6 area 62.44.127.0, а само да приемат такава.
съдържание на файла /etc/quagga/ospf6d.conf върху граничния маршрутизатор border-main.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/03/12 18:51:32 ! hostname ospf6d@border-main password ****************** service advanced-vty ! debug ospf6 lsa unknown ! interface eth0 ipv6 ospf6 cost 1 ipv6 ospf6 hello-interval 10 ipv6 ospf6 dead-interval 40 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 priority 1 ipv6 ospf6 transmit-delay 1 ipv6 ospf6 instance-id 0 ! router ospf6 router-id 62.44.127.21 redistribute connected route-map REDISTRIBUTE_CONNECTED_IPV6 interface eth0 area 62.44.127.0 ! ipv6 prefix-list REDISTRIBUTE_CONNECTED_IPV6 seq 5 permit 2001:4b58:acad:252::24/126 ipv6 prefix-list REDISTRIBUTE_CONNECTED_IPV6 seq 15 permit 2a01:288:8000::1:0:4/126 ! route-map REDISTRIBUTE_CONNECTED_IPV6 permit 10 match ipv6 address prefix-list REDISTRIBUTE_CONNECTED_IPV6 ! route-map REDISTRIBUTE_CONNECTED_IPV6 deny 20 ! line vty !
съдържание на файла /etc/quagga/ospf6d.conf върху граничния маршрутизатор border-secondary.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/03/15 11:13:57 ! hostname ospf6d@border-secondary password ****************** service advanced-vty ! debug ospf6 lsa unknown ! interface eth0 ipv6 ospf6 cost 1 ipv6 ospf6 hello-interval 10 ipv6 ospf6 dead-interval 40 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 priority 1 ipv6 ospf6 transmit-delay 1 ipv6 ospf6 instance-id 0 ! router ospf6 router-id 62.44.127.1 redistribute connected route-map REDISTRIBUTE_CONNECTED_IPV6 interface eth0 area 62.44.127.0 ! ipv6 prefix-list REDISTRIBUTE_CONNECTED seq 5 permit 2001:4b58:acad:252::2c/126 ! route-map REDISTRIBUTE_CONNECTED_IPV6 permit 10 match ipv6 address prefix-list REDISTRIBUTE_CONNECTED ! route-map REDISTRIBUTE_CONNECTED_IPV6 deny 20 ! line vty !
съдържание на файла /etc/quagga/ospf6d.conf върху маршрутизатор в бекбона lcpe-gw.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/03/12 19:23:05 ! hostname ospf6d@lcpe-gw.uni-sofia.bg password ************** service advanced-vty ! debug ospf6 lsa unknown ! interface eth0 ipv6 ospf6 cost 1 ipv6 ospf6 hello-interval 10 ipv6 ospf6 dead-interval 40 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 priority 1 ipv6 ospf6 transmit-delay 1 ipv6 ospf6 instance-id 0 ! router ospf6 router-id 62.44.127.19 interface eth0 area 62.44.127.0 ! line vty !
Поради голямата комплексност на BGP конфигурацията на граничните маршрутизатори на AS5421, по-долу е дадена само и единствено информацията касаеща конкретните BGP4+ сесии с граничните маршрутизатори на AS6802 и AS8717. Конфигурацията на демона bgpd се намира във файла /etc/quagga/bgpd.conf.
съдържание на файла /etc/quagga/bgpd.conf върху граничния маршрутизатор border-main.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/06/30 22:55:58 ! hostname bgpd@border-main password ************ service advanced-vty ! router bgp 5421 bgp router-id 62.44.127.21 no bgp default ipv4-unicast ... neighbor 2001:4b58:acad:252::25 remote-as 6802 neighbor 2001:4b58:acad:252::25 description ACAD_BORDER_IPV6 no neighbor 2001:4b58:acad:252::25 activate neighbor 2a01:288:8000::1:0:6 remote-as 8717 neighbor 2a01:288:8000::1:0:6 description SPNET_PEERING_IPV6 no neighbor 2a01:288:8000::1:0:6 activate ! address-family ipv6 network 2a01:288:8000::/35 neighbor 2001:4b58:acad:252::25 activate neighbor 2001:4b58:acad:252::25 soft-reconfiguration inbound neighbor 2001:4b58:acad:252::25 route-map ACAD_BORDER_IMPORT_IPV6 in neighbor 2001:4b58:acad:252::25 route-map PEERING_EXPORT_IPV6 out neighbor 2a01:288:8000::1:0:6 activate neighbor 2a01:288:8000::1:0:6 soft-reconfiguration inbound neighbor 2a01:288:8000::1:0:6 route-map SPNET_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::1:0:6 route-map PEERING_EXPORT_IPV6 out ... exit-address-family ! ... ipv6 prefix-list MAX_PREFIX_LENGTH_IPV6 seq 5 permit ::/0 ge 48 ... ip as-path access-list PRIVATE_AS permit _(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0- 9]|655[0-2][0-9]|6553[0-5])$ ... ! route-map PEERING_EXPORT_IPV6 permit 10 match ipv6 address PEERING_EXPORT_IPV6 ! route-map PEERING_EXPORT_IPV6 deny 20 ! ... route-map ACAD_BORDER_IMPORT_IPV6 deny 10 match ipv6 address prefix-list MAX_PREFIX_LENGTH_IPV6 ! route-map ACAD_BORDER_IMPORT_IPV6 deny 20 match as-path PRIVATE_AS ! route-map ACAD_BORDER_IMPORT_IPV6 permit 30 set community 5421:6802 ! ... route-map SPNET_BORDER_IMPORT_IPV6 deny 10 match ipv6 address prefix-list MAX_PREFIX_LENGTH_IPV6 ! route-map SPNET_BORDER_IMPORT_IPV6 deny 20 match as-path PRIVATE_AS ! route-map SPNET_BORDER_IMPORT_IPV6 permit 30 set community 5421:8717 ! ...
съдържание на файла /etc/quagga/bgpd.conf върху граничния маршрутизатор border-secondary.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/06/30 22:55:58 ! hostname bgpd@border-secondary password ************ service advanced-vty ! router bgp 5421 bgp router-id 62.44.127.1 no bgp default ipv4-unicast ... neighbor 2001:4b58:acad:252::2d remote-as 6802 neighbor 2001:4b58:acad:252::2d description ACAD_BORDER_IPV6 no neighbor 2001:4b58:acad:252::2d activate ! address-family ipv6 network 2a01:288:8000::/35 neighbor 2001:4b58:acad:252::2d activate neighbor 2001:4b58:acad:252::2d soft-reconfiguration inbound neighbor 2001:4b58:acad:252::2d route-map ACAD_BORDER_IMPORT_IPV6 in neighbor 2001:4b58:acad:252::2d route-map PEERING_EXPORT_IPV6 out ... exit-address-family ! ... ipv6 prefix-list MAX_PREFIX_LENGTH_IPV6 seq 5 permit ::/0 ge 48 ... ip as-path access-list PRIVATE_AS permit _(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0- 9]|655[0-2][0-9]|6553[0-5])$ ... ! route-map PEERING_EXPORT_IPV6 permit 10 match ipv6 address PEERING_EXPORT_IPV6 ! route-map PEERING_EXPORT_IPV6 deny 20 ! ... route-map ACAD_BORDER_IMPORT_IPV6 deny 10 match ipv6 address prefix-list MAX_PREFIX_LENGTH_IPV6 ! route-map ACAD_BORDER_IMPORT_IPV6 deny 20 match as-path PRIVATE_AS ! route-map ACAD_BORDER_IMPORT_IPV6 permit 30 set community 5421:6802 ! ...
Поради голямата комплексност на BGP конфигурацията на граничните маршрутизатори на AS5421, по-долу е дадена само и единствено информацията касаеща конкретните BGP4+ сесии с маршрутизаторите в бекбон мрежата на Университета. Конфигурацията на демона bgpd се намира във файла /etc/quagga/bgpd.conf.
съдържание на файла /etc/quagga/bgpd.conf върху граничния маршрутизатор border-main.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/06/30 22:55:58 ! hostname bgpd@border-main password ********** service advanced-vty ! router bgp 5421 bgp router-id 62.44.127.21 no bgp default ipv4-unicast ... neighbor LOZ_CAMPUS_IPV6 peer-group neighbor LOZ_CAMPUS_IPV6 remote-as 5421 no neighbor LOZ_CAMPUS_IPV6 activate neighbor 2a01:288:8000::1 description BORDER-SECONDARY.UNI-SOFIA.BG no neighbor 2a01:288:8000::1 activate neighbor 2a01:288:8000::11 description LOZ-GW_IPV6 no neighbor 2a01:288:8000::11 activate neighbor 2a01:288:8000::15 description FMI_BORDER_IPV6 no neighbor 2a01:288:8000::15 activate neighbor 2a01:288:8000::16 description PHYS_BORDER_IPV6 no neighbor 2a01:288:8000::16 activate neighbor 2a01:288:8000::19 description LCPE_BORDER_IPV6 no neighbor 2a01:288:8000::19 activate neighbor 2a01:288:8000::23 description CHEM_BORDER_IPV6 no neighbor 2a01:288:8000::23 activate ... address-family ipv6 network 2a01:288:8000::/35 neighbor LOZ_CAMPUS_IPV6 activate neighbor LOZ_CAMPUS_IPV6 route-reflector-client neighbor LOZ_CAMPUS_IPV6 soft-reconfiguration inbound neighbor LOZ_CAMPUS_IPV6 route-map LOZ_CAMPUS_EXPORT_IPV6 out neighbor 2a01:288:8000::1 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::11 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::11 route-map LOZ_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::15 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::15 route-map FMI_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::16 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::16 route-map PHYS_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::19 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::19 route-map LCPE_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::23 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::23 route-map CHEM_BORDER_IMPORT_IPV6 in ... exit-address-family ! ipv6 access-list CHEM_BORDER_IMPORT_IPV6 permit 2a01:288:8004::/48 exact-match ipv6 access-list FMI_BORDER_IMPORT_IPV6 permit 2a01:288:8002::/48 exact-match ipv6 access-list LCPE_BORDER_IMPORT_IPV6 permit 2a01:288:8001::/48 exact-match ipv6 access-list LOZ_BORDER_IMPORT_IPV6 permit 2a01:288:8003::/48 exact-match ipv6 access-list LOZ_BORDER_IMPORT_IPV6 permit 2a01:288:8000:aaaa::/64 exact-match ipv6 access-list PHYS_BORDER_IMPORT_IPV6 permit 2a01:288:8005::/48 exact-match ... ! route-map LOZ_BORDER_IMPORT_IPV6 permit 10 match ipv6 address LOZ_BORDER_IMPORT_IPV6 ! route-map LOZ_BORDER_IMPORT_IPV6 deny 20 ! route-map CHEM_BORDER_IMPORT_IPV6 permit 10 match ipv6 address CHEM_BORDER_IMPORT_IPV6 ! route-map CHEM_BORDER_IMPORT_IPV6 deny 20 ! route-map PHYS_BORDER_IMPORT_IPV6 permit 10 match ipv6 address PHYS_BORDER_IMPORT_IPV6 ! route-map PHYS_BORDER_IMPORT_IPV6 deny 20 ! route-map FMI_BORDER_IMPORT_IPV6 permit 10 match ipv6 address FMI_BORDER_IMPORT_IPV6 ! route-map FMI_BORDER_IMPORT_IPV6 deny 20 ! route-map LCPE_BORDER_IMPORT_IPV6 permit 10 match ipv6 address LCPE_BORDER_IMPORT_IPV6 ! route-map LCPE_BORDER_IMPORT_IPV6 deny 20 ! ...
съдържание на файла /etc/quagga/bgpd.conf върху граничния маршрутизатор border-secondary.uni-sofia.bg:
! ! Zebra configuration saved from vty ! 2008/06/30 22:55:58 ! hostname bgpd@border-secondary password ********** service advanced-vty ! router bgp 5421 bgp router-id 62.44.127.1 no bgp default ipv4-unicast ... neighbor LOZ_CAMPUS_IPV6 peer-group neighbor LOZ_CAMPUS_IPV6 remote-as 5421 no neighbor LOZ_CAMPUS_IPV6 activate neighbor 2a01:288:8000::a description BORDER-MAIN.UNI-SOFIA.BG no neighbor 2a01:288:8000::a activate neighbor 2a01:288:8000::11 description LOZ-GW_IPV6 no neighbor 2a01:288:8000::11 activate neighbor 2a01:288:8000::15 description FMI_BORDER_IPV6 no neighbor 2a01:288:8000::15 activate neighbor 2a01:288:8000::16 description PHYS_BORDER_IPV6 no neighbor 2a01:288:8000::16 activate neighbor 2a01:288:8000::19 description LCPE_BORDER_IPV6 no neighbor 2a01:288:8000::19 activate neighbor 2a01:288:8000::23 description CHEM_BORDER_IPV6 no neighbor 2a01:288:8000::23 activate ... address-family ipv6 network 2a01:288:8000::/35 neighbor LOZ_CAMPUS_IPV6 activate neighbor LOZ_CAMPUS_IPV6 route-reflector-client neighbor LOZ_CAMPUS_IPV6 soft-reconfiguration inbound neighbor LOZ_CAMPUS_IPV6 route-map LOZ_CAMPUS_EXPORT_IPV6 out neighbor 2a01:288:8000::a peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::11 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::11 route-map LOZ_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::15 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::15 route-map FMI_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::16 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::16 route-map PHYS_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::19 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::19 route-map LCPE_BORDER_IMPORT_IPV6 in neighbor 2a01:288:8000::23 peer-group LOZ_CAMPUS_IPV6 neighbor 2a01:288:8000::23 route-map CHEM_BORDER_IMPORT_IPV6 in ... exit-address-family ! ipv6 access-list CHEM_BORDER_IMPORT_IPV6 permit 2a01:288:8004::/48 exact-match ipv6 access-list FMI_BORDER_IMPORT_IPV6 permit 2a01:288:8002::/48 exact-match ipv6 access-list LCPE_BORDER_IMPORT_IPV6 permit 2a01:288:8001::/48 exact-match ipv6 access-list LOZ_BORDER_IMPORT_IPV6 permit 2a01:288:8003::/48 exact-match ipv6 access-list LOZ_BORDER_IMPORT_IPV6 permit 2a01:288:8000:aaaa::/64 exact-match ipv6 access-list PHYS_BORDER_IMPORT_IPV6 permit 2a01:288:8005::/48 exact-match ... ! route-map LOZ_BORDER_IMPORT_IPV6 permit 10 match ipv6 address LOZ_BORDER_IMPORT_IPV6 ! route-map LOZ_BORDER_IMPORT_IPV6 deny 20 ! route-map CHEM_BORDER_IMPORT_IPV6 permit 10 match ipv6 address CHEM_BORDER_IMPORT_IPV6 ! route-map CHEM_BORDER_IMPORT_IPV6 deny 20 ! route-map PHYS_BORDER_IMPORT_IPV6 permit 10 match ipv6 address PHYS_BORDER_IMPORT_IPV6 ! route-map PHYS_BORDER_IMPORT_IPV6 deny 20 ! route-map FMI_BORDER_IMPORT_IPV6 permit 10 match ipv6 address FMI_BORDER_IMPORT_IPV6 ! route-map FMI_BORDER_IMPORT_IPV6 deny 20 ! route-map LCPE_BORDER_IMPORT_IPV6 permit 10 match ipv6 address LCPE_BORDER_IMPORT_IPV6 ! route-map LCPE_BORDER_IMPORT_IPV6 deny 20 ! ...
Изложената по-долу конфигурация касае маршрутизаторите на самостоятелните звена, свързани в бекбон мрежата на Университета. По-долу е дадена само и единствено информацията касаеща конкретните BGP4+ сесии. Конфигурацията на демона bgpd се намира във файла /etc/quagga/bgpd.conf.
! ! Zebra configuration saved from vty ! 2008/06/17 22:57:18 ! hostname bgpd@lcpe-gw.uni-sofia.bg password ************ service advanced-vty ! router bgp 5421 bgp router-id 62.44.127.19 neighbor 2a01:288:8000::1 remote-as 5421 no neighbor 2a01:288:8000::1 activate neighbor 2a01:288:8000::a remote-as 5421 no neighbor 2a01:288:8000::a activate ... address-family ipv6 network 2a01:288:8001::/48 neighbor 2a01:288:8000::1 activate neighbor 2a01:288:8000::1 soft-reconfiguration inbound neighbor 2a01:288:8000::1 route-map LCPE_TO_SU_IPV6_MAP out neighbor 2a01:288:8000::a activate neighbor 2a01:288:8000::a soft-reconfiguration inbound neighbor 2a01:288:8000::a route-map LCPE_TO_SU_IPV6_MAP out ... exit-address-family ! ipv6 access-list LCPE_TO_SU permit 2a01:288:8001::/48 exact-match ... ! route-map LCPE_TO_SU_IPV6_MAP permit 10 match ipv6 address LCPE_TO_SU ! route-map LCPE_TO_SU_IPV6_MAP deny 20 ! ...
Доколкото адресното IPv6 пространство на Университета не е директно заявено от RIR RIPE, а се използва през LIR (за случая "Spectrum NET"), то не може да се регистрират директно в зоната. Именно заради това делегирането на ip6.arpa зоните на домейни за IPv6 адресните мрежови пространства на Софийския Университет, става йерархично през сървърите за имена на LIR "Spectrum NET". По-долу е описана схемата на ip6.arpa делегирането.
На 3 октомври 2006 година RIPE NCC в ролята си на RIR получава правата да алокира за своите членове (LIR) адресни алокации от сегмента 2a00:0000::/12. Този факт е отразен в списъка с алокации публикуван от IANA на адрес:
http://www.iana.org/assignments/ipv6-unicast-address-assignments
Ето и границите на този сегмент, дължината на префикса и типа му (информацията е получена чрез инструмента sipcalc):
[IPV6 INFO]
Expanded Address - 2a01:0000:0000:0000:0000:0000:0000:0000
Compressed address - 2a01::
Subnet prefix (masked) - 2a00:0:0:0:0:0:0:0/12
Address ID (masked) - 1:0:0:0:0:0:0:0/12
Prefix address - fff0:0:0:0:0:0:0:0
Prefix length - 12
Address type - Aggregatable Global Unicast Addresses
Network range - 2a00:0000:0000:0000:0000:0000:0000:0000 -
2a0f:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Както се вижда от горната информация, йерархията в ip6.arpa следва да започне чрез зоната на домейна 0.a.2.ip6.arpa, доколкото "2a0" е постояната "представка" по протежение на цялото делене на сегмента 2a00:0000::/12 на адресни подсегменти. Когато LIR "Spectrum NET" е получил за управление и разпределяне адресното пространство 2a01:288::/32, в зоната на домейна 0.a.2.ip6.arpa е извършено делегиране на ip6.arpa домейна 8.8.2.0.1.0.a.2.ip6.arpa. Зоната на последния се обслужва върху сървърите за имена ns.spnet.net и purgatory.spnet.net.
Ако се види информацията за адресния сегмент на LIR "Spectrum NET" (информацията е получена чрез инструмента sipcalc):
[IPV6 INFO]
Expanded Address - 2a01:0288:0000:0000:0000:0000:0000:0000
Compressed address - 2a01:288::
Subnet prefix (masked) - 2a01:288:0:0:0:0:0:0/32
Address ID (masked) - 0:0:0:0:0:0:0:0/32
Prefix address - ffff:ffff:0:0:0:0:0:0
Prefix length - 32
Address type - Aggregatable Global Unicast Addresses
Network range - 2a01:0288:0000:0000:0000:0000:0000:0000 -
2a01:0288:ffff:ffff:ffff:ffff:ffff:ffff
и тази за предоставения за използване на Софийския Университет "Св. Климент Охридски":
[IPV6 INFO]
Expanded Address - 2a01:0288:8000:0000:0000:0000:0000:0000
Compressed address - 2a01:288:8000::
Subnet prefix (masked) - 2a01:288:8000:0:0:0:0:0/35
Address ID (masked) - 0:0:0:0:0:0:0:0/35
Prefix address - ffff:ffff:e000:0:0:0:0:0
Prefix length - 35
Address type - Aggregatable Global Unicast Addresses
Network range - 2a01:0288:8000:0000:0000:0000:0000:0000 -
2a01:0288:9fff:ffff:ffff:ffff:ffff:ffff
става ясно, че в зоната на домейна 8.8.2.0.1.0.a.2.ip6.arpa трабва да бъдат делегирани домейните 8.8.8.2.0.1.0.a.2.ip6.arpa и 9.8.8.2.0.1.0.a.2.ip6.arpa.
Делегирането на тези домейни следва "glue AAAA" схема, описана в документа "Напълно автономно делегиране на in-addr.arpa и ip6.arpa поддомейни". Ето как се извършва то за двата ip6.arpa домейна:
домейн 8.8.8.2.0.1.0.a.2.ip6.arpa:
"glue AAAA":
@ORIGIN 8.8.8.2.0.1.0.a.2.ip6.arpa ns1 A 62.44.96.1 ns2 A 62.44.96.7 ns3 AAAA 2a01:288:8000:aaaa::1 ns4 AAAA 2a01:288:8000:aaaa::7
NS ресурсни записи:
@ORIGIN 8.8.8.2.0.1.0.a.2.ip6.arpa NS ns1 NS ns2 NS ns3 NS ns4
домейн 9.8.8.2.0.1.0.a.2.ip6.arpa:
"glue AAAA":
@ORIGIN 9.8.8.2.0.1.0.a.2.ip6.arpa ns1 A 62.44.96.1 ns2 A 62.44.96.7 ns3 AAAA 2a01:288:8000:aaaa::1 ns4 AAAA 2a01:288:8000:aaaa::7
NS ресурсни записи:
@ORIGIN 9.8.8.2.0.1.0.a.2.ip6.arpa NS ns1 NS ns2 NS ns3 NS ns4
Ето пример как изглежда отговорът на заявка за извличане на информация за делегирането чрез инструмента dig:
$ dig @ns.uni-sofia.bg -t ns 8.8.8.2.0.1.0.a.2.ip6.arpa ; <<>> DiG 9.4.1-P1 <<>> @ns.uni-sofia.bg -t ns 8.8.8.2.0.1.0.a.2.ip6.arpa ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32979 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;8.8.8.2.0.1.0.a.2.ip6.arpa. IN NS ;; ANSWER SECTION: 8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN NS ns2.8.8.8.2.0.1.0.a.2.ip6.arpa. 8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN NS ns3.8.8.8.2.0.1.0.a.2.ip6.arpa. 8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN NS ns4.8.8.8.2.0.1.0.a.2.ip6.arpa. 8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN NS ns1.8.8.8.2.0.1.0.a.2.ip6.arpa. ;; ADDITIONAL SECTION: ns1.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN A 62.44.96.1 ns2.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN A 62.44.96.7 ns3.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN AAAA 2a01:288:8000:aaaa::1 ns4.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400 IN AAAA 2a01:288:8000:aaaa::7 ;; Query time: 4 msec ;; SERVER: 2a01:288:8000:aaaa::1#53(2a01:288:8000:aaaa::1) ;; WHEN: Tue Jul 22 14:53:12 2008 ;; MSG SIZE rcvd: 204
Ясно се вижда информацията за "glue AAAA" ресурсните записи, подавана в "ADDITIONAL SECTION".
Съдържанието на зоната на домейна 0.a.2.ip6.arpa е електронно подписано от RIPE NCC. Съществува автоматизация в рамките на функционалностите, които предлага RIPE DB, чрез която може всеки LIR да извърши DNSSEC делегиране на своята ip6.arpa. След това той може да делегира ip6.arpa домейните на своите клиенти и така LIR субекта влиза в ролята на DNSSEC медиатор.
Теоретично схемата би изглеждала така. Техническите лица на LIR "Spectrum NET" подписват зоната на домейна 8.8.2.0.1.0.a.2.ip6.arpa. Чрез автоматизираната система за актуализация на RIPE DB и процедурата описана в документа "Procedure for Requesting DNSSEC Delegations", генерираните DS ресурсни записи се поставят в базата на RIPE, а оттам чрез периодични актуализации те попадат в зоната на домейна 0.a.2.ip6.arpa, като придружаващи делегирането на домейна 8.8.2.0.1.0.a.2.ip6.arpa. След като делегирането влезе в сила по сървърите за имена съдържащи зоната на домейна 0.a.2.ip6.arpa, LIR оператора следва да съобщи на техническите лица управляващи DNS услугата на Университета, че началото на делегирането е положено и вече може да се извършва делегиране на клиентски ip6.arpa домейни чрез DS ресурсни записи. След това следва подписване на зоната на домейните 8.8.8.2.0.1.0.a.2.ip6.arpa и 9.8.8.2.0.1.0.a.2.ip6.arpa и изпращането на DS записите за тях на оператора на зоната на домейна 8.8.2.0.1.0.a.2.ip6.arpa. Поставяйки там DS записите, последният ще продължи веригата на удостоверяване на RIPE DB към съдържанието на зоните на домейните 8.8.8.2.0.1.0.a.2.ip6.arpa и 9.8.8.2.0.1.0.a.2.ip6.arpa.
За момента тази схема се натъква на един основен проблем и той е липсата на DNSSEC поддръжка от страна на софтуерния продукт PowerDNS, който се използва за реализиране на DNS услугата в LIR "Spectrum NET". Надеждата е, че в новата версия на софтуера ще има възможност за поддръжка на DNSSEC, което ще даде възможност за продължаване на веригата на DNSSEC делегиране от RIPE до Софийския Университет.
Към момента би следвало формата за управление на домейни на Register.BG да допуска обявяване на "glue AAAA" ресурсни записи при делегиране на домейни в TLD BG. Благодарности към Даниел Калчев от Register.BG за подкрепата на идеята ни за IPv6 делегиране.
Всички маршрутизатори включени в рефлекторната схема на AS5421 използват операционна система Linux, дистрибуция CentOS 5 (последна мажорна актуализация). Софтуерът за управление на динамичната маршрутизация е Quagga във версия 0.98.6 - дистрибутивен пакет за CentOS 5.
Всички маршрутизатори работят в режим "dual-stack", което означава, че всеки от тях извършва едновремено маршрутизация на IPv4 и IPv6 трафик.
Когато се налага пакетна филтрация, за целта се използва пакета iptables-ipv6 от дистрибуцията, което е реализация на netfilter за IPv6.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]
