Интернет-протокол IPv6 для развития сети СаО РАН

УДК 004.7

ИНТЕРНЕТ-ПРОТОКОЛ IPv6 ДЛЯ РАЗВИТИЯ СЕТИ САО РАН

© 2020 В. Н. Черненков1*

Специальная астрофизическая обсерватория РАН, Нижний Архыз, 369167 Россия Поступила в редакцию 13 августа 2018 года; после доработки 16 июля 2019 года; принята к публикации 16 июля 2019 года

В работе описаны требования к современной компьютерной сети научной организации, в частности, локальной сети Специальной астрофизической обсерватории Российской академии наук (САО РАН). Определен выбор направления в развитии базовых средств обеспечения наблюдательного процесса, основанных на сервисах в локальной сетевой инфраструктуре САО. Это поможет автоматизировать административное сопровождение сети, исключит влияние человеческого фактора на ее надежность и упростит ее обслуживание. Обоснована реализованная низкоранговая структура построения сети на основе высокопроизводительных коммутаторов Ethernet. Показана перспективность использования интернет-протоколов шестой версии IPv6 взамен и в дополнение к IPv4 для осуществления преимущественно «безлюдного» административного сопровождения сетей, минимизирующего ошибки ручного режима. Предложено развитие мультиплатформенной сети с помощью перспективных технологий, поддерживаемых IPv6, обеспечивающих внедрение практически самонастраеваемой конфигурации. Описаны способы клиент-серверной реализации основных сетевых сервисов обсерватории.

Ключевые слова: разное

1. ВВЕДЕНИЕ

В САО РАН (обсерватории, для краткости) сетевые технологии для автоматизации наблюдений и сбора данных активно начали внедряться с 1986 года, а IP (Internet Protocol) — практически сразу с появлением недорогих телефонных модемов и широкополосных сетевых адаптеров для персональных компьютеров (ArcNet, Ethernet) в начале 90-х (Chernenkov and Shergin 1998).

В 2018 году исполняется 20 лет с момента публикации Deering and Hinden (1998) современной редакции интернет-протокола шестой версии — IPv6. Тем не менее не теряет актуальности обоснование замены им IPv4, пока доминирующего в обеспечении ресурсов глобального Интернет. Целью настоящей работы является исследование применимости IPv6 для решения задач планомерного развития и сопровождения сетей обсерватории. Казалось бы, развитие сети обсерватории является рутинной инженерной задачей. Однако выбор направления в развитии ее технологической основы важен для разработки базовых методик наблюдательного процесса, научной аппаратуры, серверов обработки наблюдательных данных и программных продуктов, основанных на сетевых технологиях и глубоко интегрированных в соответствующие сервисы. Требуется тщательное изучение и тестирование этих средств и сервисов,

E-mail: vch@sao.ru

чтобы их использование не привело к усложнению получения, переноса, обработки или искажению научных данных. Следование мировой тенденции внедрения перспективных технологий является необходимой мерой поддержания востребованности научной инструментальной базы и наблюдательных архивов САО РАН.

2. ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К 1Р-СЕТИ ОБСЕРВАТОРИИ

Область исследования сетевых технологий и их применимости определяется техническими требованиями к сети научно-исследовательской организации. Ниже перечислены основные из них:

1. Производительность сети должна быть согласована с потоком наблюдательных данных, передаваемых по сети в процессе их получения, архивизации, обработки и, по-возможности, соответствовать современному состоянию в мировой практике.

2. Структура сети должна обеспечивать простоту переноса научного оборудования (компьютеров), в первую очередь, такого, которое управляется по сети удаленно.

3. Сетевое оборудование должно обеспечивать круглосуточные наблюдения или сервисные работы на всех телескопах обсерватории. Для повышения надежности желательно минимизировать

влияние человеческого фактора на настройки сетевых элементов, в частности, так чтобы подключение мультиплатформенных клиентов сети не требовало ручного вмешательство администратора (Zero Configuration).

4. Требования к сервисному обеспечению и адресному пространству сети обсерватории определяются следующими факторами. Как правило, все штатные сотрудники (440 человек) (Vlasyuk 2017), аспиранты, приезжающие студенты и наблюдатели нуждаются как во внутрисетевом, так и Интернет-доступе. Только за последние 3 года в проводной сети Нижней и Верхней научных площадок зарегистрировано 770 уникальных сетевых адресов (MAC).

5. Сеть должна иметь достаточную периферийную защиту со стороны Интернет и быть топологически максимально связной для внутреннего обмена данными между клиентскими компьютерами, серверами и научным оборудованием.

6. Обязательна автоматизация мониторинга основного оборудования и линий связи.

Из перечисленного видим, что ничего сверх обычного от сети не требуется, в том числе какая-либо разработка дорогостоящих уникальных технологий. Однако с помощью устаревающих средств IPv4 реализация требований пп. 2—5 представляется нетривиальной.

Несмотря на то, что разработка нового протокола IP ведется давно, и он уже тщательно проработан и отлажен, существуют объективные причины задержки внедрения IPv6. Назовем основные из них, актуальные для САО РАН:

Некоторое количество дешевого сетевого оборудования еще не предусматривает работы в сетях IPv6 в полной мере или не отлажено для нее, поскольку рассчитано на сверхмалые домашние и офисные сети (SOHO), подключаемые к Интернет-провайдеру по IPv4 c существенным адресным ограничением.

Проблема нехватки глобальных IP-адресов, которая имелась из-за использования IPv4 с 32-битным адресным полем, была частично снята с помощью сетевой адресной трансляции (NAT) для ассиметричного доступа в Интернет с помощью микророутеров, в том числе беспроводных.

Наличие в пользовании сторонних сетевых приложений, основой для которых является исключительно IPv4. Их перечень постепенно сокращается.

Крупнейшие российские сетевые операторы, такие как «Ростелеком», не спешат с внедрением сервиса IPv6, экономя ограниченный адресный

ресурс. Что весьма парадоксально, поскольку по сведениям Google в 2018 году (Google 2015) степень адаптации ресурсов Интернет к IPv6 достигла 20% (рис. A.2).

3. ПРОБЛЕМЫ РАЗВИТИЯ ЛОКАЛЬНОЙ СЕТИ IPv4

К сожалению, использование IPv4 ведет к трудностям при создании локальной сети научной организации, более крупной, чем сеть SOHO с Интернет-подключением. При слабой централизации или без жесткого администрирования развитие сети становится хаотичным как по структуре, так и по функционированию. Возникают или слабосвязанные сегменты сети, объединяемые PC-роутерами — серверами лабораторий, или крупные конгломераты IPv4-сети c существенным широковещательным трафиком и слабоуправляемым назначением интернет-адресов. Очевиден конфликт требования мобильности компьютеров, персональных сетевых устройств с необходимостью жесткой адресной привязки к сетевой структуре и административным управлением адресами. При этом были случаи неправильной и деструктивной самостоятельной настройки сетевых интерфейсов, что вело к сбоям и даже потерям наблюдательного времени. Попытки же внедрить динамическое назначение IPv4 адресов с помощью сервиса DHCP в лучшем случае охватывали беспроводный WiFi-сегмент, увеличение масштаба которого может привести к еще большей нестабильности.

4. ПРЕИМУЩЕСТВА IPv6 ДЛЯ ЛОКАЛЬНОЙ СЕТИ ОРГАНИЗАЦИИ

Обычно считают, и это отчасти правильно, что полезность внедрения IPv6 для Интернет состоит в решении известной проблемы нехватки адресного пространства, которое расширяется благодаря выделению 128 бит на адрес и практически неисчерпаемого даже в далекой перспективе. Для случая локальной сети организации это совершенно не главное, хотя и эта проблема проявляется при неудачном разбиении IPv4-сети на сегменты. Однако следует обратить внимание на другие полезные свойства IPv6. К ним относятся:

1. Механизм автоматического назначения адресов сетевых устройств (SLAAC) c помощью ND RA — Neigbour Discovery and Router Advertisment.

2. Механизм исключения адресных конфликтов на уровне функционирования операционной системы (ядра), который, как правило, недоступен для отключения на уровне пользователя и исключает непреднамеренные ошибки.

Jan 2009 Jan 2010 Jan 2011 Jan2012 Jan2013 Jan2014 Jan2015 Jan2016 Jan2017 Jan2018

Рис. A.2. Процентная доля поисковых запросов пользователей IPv6 Google (2015).

3. Исключение сборки-разборки сетевых пакетов в промежуточных маршрутизаторах из-за возможной фрагментации, что резко сокращает требования к ресурсам активного оборудования при масштабировании размеров и производительности сети. Сборка-разборка пакетов IPv6 производится только на оконечных сетевых устройствах. При этом максимальный размер одиночного пакета (MTU) как правило фиксирован. Это не только повышает производительность, но и устойчивость соединений к возможному вмешательству или искажению информации на самом низком уровне протоколов, облегчая защиту соединений. Примером может послужить тот факт, что ежемесячно на центральный маршрутизатор САО РАН из Интернет производится более сотни атак фрагментирования, приводящие к системным сообщениям о сбоях в резервировании буферов ввода-вывода. Отсутствие необходимости промежуточной сборки пакетов существенно упрощает реализацию мобильного подключения и безразрывное переключение клиентских устройств между беспроводными точками доступа.

4. Исключение необходимости ARP (Address Resolution Protocol) — основного протокола для установки соответствия интернет-адреса физическому адресу сетевого интерфейса. Для ARP обязательна рассылка широковещательных (broadcast) пакетов внутри сетевого сегмента, что может привести к образованию скачкообразных нагрузок в передаче при увеличении размеров сети и количества активных сетевых устройств — компьютеров и коммутаторов. Генерация таких

«штормов» особенно опасна для функционирования сети в случаях непреднамеренного «за-кольцовывания» сегментов сети при ошибочных настройках сетевых устройств или каналов, например WiFi.

5. Стек протоколов IPv6 встроен и хорошо отлажен практически во всех современных операционных системах для серверов, персональных компьютеров и мобильных устройств. Исключение могут составлять старые сетевые адаптеры некоторых принтеров, сканеров, ИБП и тому подобных периферийных устройств.

6. Использование IPv6 не препятствует IPv4 (Nordmark and Gilligan 2005), не конфликтует с ним, и при грамотном подходе, может внедряться постепенно

без остановки функционирования сети.

5. АДРЕСАЦИЯ В ЛОКАЛЬНОЙ СЕТИ

В сетях IPv4 соответствие 32-битного IP адреса 48-битному физическому адресу сетевого адаптера (MAC) не могло быть полностью однозначным. Устройство с нужным IP находилось посредством широковещательного ARP-запроса. Для IPv6 назначение адресов иное и в большей степени может быть автоматизировано, поскольку его 128-битный адрес может полностью содержать и необходимые 48 бит MAC. Стандарт адресации в сети IPv6 предусматривает несколько способов формирования как префиксной, так и суффиксной частей 128-битного адресного пространства. Наиболее привлекательным, учитывая преемственность от сетей IPv4, нам показался способ составления адреса,

Таблица 1. Сегментация SAO-NET

№ подсети Назначение

2002:3е4с:2601:0:/64 сеть Нижней и Верхней научной площадки

2002:3е4с:2601:1:/64 \ViFi

2002:3е4с:2601:2:/64 сеть механических мастерских

2002:3е4с:2601:3:/64 Сатриз-ЫЕТ

2002:55ac:bec2:0:/64 сеть РАТАН-600

2002:55ac:bec2:8:/64 оптический линк РАТАН-600—ННП

основанный на стандарте инкапсулирования пакетов IPv6 в пакеты IPv4 (Carpenter and Moore 2001). Это не означает, что в локальной сети мы будем прибегать к такой инкапсуляции, но позволит нам уже на начальном этапе внедрения получить корректные маршрутизируемые адреса IPv6 без специального обращения к провайдеру Интернет. При этом адрес сетевого элемента составляется из следующих частей. В начале адреса 2002 (шестнадцатеричное) — признак переходного способа формирования суффикса из глобального адреса IPv4 «IPv6to4», затем глобальный адрес IPv4, выданный провайдером, преобразованный в 8 шестнадцатеричных символов. Далее 4 цифры определяют один из возможных 164 сегментов локальной сети. Итого под фиксированную часть (префикс) будет задействована половина из 128-битного адреса. Остальные 64 бита формируются по стандарту eui-64 (Abley 2013) из 48-битного уникального MAC-адреса интерфейса конкретного сетевого устройства. Прием префикса от маршрутизатора и дополнение до полного адреса ОС компьютера производит автоматически с помощью сервиса ND RA. Примером является адрес сервера cats: 2002:3e4c:2601:0000:12bf:48ff:febb:e390. Тут значение 3e4c:2601 сформировано из адреса 62.76.38.1 и подсети 0000. Последовательность из

и ^ TT TT

одних нулей в записи обычно сокращают до :: .

5.1. IPv6 и адресная сегментация локальной сети

При внедрении сетей IPv6 отсутствует острая необходимость сегментации, аналогичной разбиению сетей прошлого поколения, благодаря отказу от рассылки широковещательных ARP-запросов. Тем не менее существующую структуру сети очевидно не стоит менять революционным путем. Хотя

сегментация локальной сети может доставить дополнительное неудобство, она может быть оправдана необходимостью повышения безопасности в выделенных подсетях, обеспечить независимое администрирование при территориальном разнесении или выделении зон ответственности. Префикс сетей IPv6 совместно с механизмом SLAAC позволяет выделить 16 байт для назначения номера подсети внутри одной сети, построенной всего из одного выделенного IPv4 — глобального адреса провайдера. Напомним, что это эквивалентно количеству в 65536 подсетей. Для каждого сегмента администратором должен быть определен интерфейс физической или виртуальной сети для коммутатора 3-го уровня1 (маршрутизатора) и настроен сервис ND RA, тем самым мы обеспечим автоматическое переназначение адреса конкретного компьютера при переносе его из одного сегмента в другой. Связность сегментов мы обеспечиваем маршрутизацией по OSPFv3 (Cisco Systems 2016, Coltun et al. 2008) с помощью оборудования Cisco Systems, Inc.

Возможные номера сегментов локальной сети SAO-NET приведены в таблице 1.

5.2. Особенности настройки IPv6 для регистрации в DNS

Клиенту локальной сети IPv6 обычно нет необходимости специально настраивать сетевой доступ, поскольку обычно достаточно настроек по умолчанию. Если же компьютеру необходимо сетевое имя, то перед регистрацией в службе DNS администратору необходимо проверить настройку системы этого компьютера. Для постоянной регистрации имен серверов следует отключить приватный (рандомизированный) способ присвоения суффиксной части адреса (Narten et al. 2007), оставив фиксированный адрес в формате eui-64. Поскольку пользователю, возможно, непросто сориентироваться в описаниях различных операционных систем, сведем нужные фрагменты в короткую инструкцию в виде таблицы 2.

5.3. Настройка приоритета версии IP

Обычно в настройках операционной системы сервера используется двойной стек адресации: IPv4 совместно с IPv6. Как правило, использование более современного IPv6 по-умолчанию установлено с большим приоритетом. Но это можно изменить, для чего необходимо воспользоваться соответствующим руководством (MS Support

'Устройства, реализующие уровни, общепринятой

7-уровневой иерархической модели сетевых протоколов

OSI-ISO

Таблица 2. Запрет замены MAC на рандомизированный адрес

Операционная система Действие

MS Windows Выполнить однократно:

netsh interface ipv6 set global randomizeidentifiers=disabled store =active

netsh interface ipv6 set global randomizeidentifiers=disabled store =persistent

netsh interface ipv6 set privacy state=disabled store=active

netsh interface ipv6 set privacy state=disabled store=persistent

OSX Выполнить:

sudo sysctl -w net.inet6 ip6.use_tempaddr=0

В/etc/sysctl.conf вставить

net.inet6.ip6.use_tempaddr=0

Linux В/etc/sysconfig/network- scripts/ifcfg-«интерфейc» вставить

IPV6_PRIVACY=no

2012). Например в ОС Linux для максимального уменьшения приоритета IPv6 необходимо отредактировать файл /etc/gai.conf, добавив строку

precedence::ffff:0:0/96 100

Протестированные нами основные сервисы, необходимые для функционирования сети обсерватории, перечислены в таблице 3.

5.4. Автоматизация настройки рабочих мест для выхода в Интернет

Поскольку Интернет-доступ обсерватории обеспечивает провайдер «Ростелеком» и только по протоколам IPv4, то пользователю необходимо настроить свой браузер и системное окружение на использование DNS и proxy-сервера. Автоматическую настройку реализуем с помощью сервиса DHCPv6. Запуск и настройку DHCPv6 делаем на коммутаторах (Cisco Systems 2016) каждого сегмента сети совместно с ND RA, при этом протокол DHCPv6 будем использовать только для выдачи информации об адресах службы DNS и proxy. Таким образом, главное отличие от использования DHCPv4 в том, что и при отказе сервиса DHCP клиентский компьютер гарантированно получит уникальный и корректный адрес, но настройку вспомогательных сервисов необходимо будет произвести вручную, что не совсем удобно, но не так критично, как при отказе DHCP в сети IPv4. Стоит также учесть, что обычно адреса DNS и proxy статичны и доступны из всех сегментов

локальной сети, то есть необязательно подлежат перепрописыванию при переносе компьютера. Иными словами, внедрение IPv6 позволяет разделить механизмы сервисов основной адресации на базе SLAAC и второстепенных, наследуемых от IPv4.

Задача proxy-сервера, в первую очередь, как и раньше, состоит в том, чтобы позволить клиенту с локальными (немаршрутизируемыми вовне) адресами получить доступ к контенту Интернет IPv4, в том числе кэшируемому на дисках сервера для ускорения. Для этого на Linux-сервере с двойным стеком IPv4/IPv6 соответствующим стандартным образом настраиваем приложение Squid (Chernenkov et al. 2001). Оно должно обрабатывать оба типа входящих запросов независимо от версии IP, а обращаться к внешним серверам только по адресам IPv4. Для этого в файле конфигурации /etc/squid/squid.conf надо добавить запись

dns_v4_first on

Прочие способы IPv4 он-лайн доступа на внешние ресурсы — терминальный SSH и тому подобные — можно также организовать через промежуточный сервер с двойным стеком адресации. При этом на сервер можно установить программный пакет TAYGA (Lutchansky 2011, Opredelennov 2016), который организует адресную трансляцию выделенного пула клиентов IPv6 в соответствующее количество внешних IPv4-адресов (NAT64) (Carpenter and Moore 2001,

ЧЕРНЕНКОВ Таблица 3. Сервисы в SAO-NET

Сервис Подержка IPv6 ОС Сервера ОС Клиента

SSH Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

FTP Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

SAMBA Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

SMTP Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

РОР[2,3] Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

IMAP[S] Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

NFS Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

NNTP Да Linux Linux, MS Windows, MAC OSX, iOS

HTTP[S] Да Linux Linux, MS Windows, MAC OSX, iOS

NTP Да Linux Linux, MS Windows, MAC OSX, iOS

Xll Да Linux Linux, MS Windows, MAC OSX, iOS

RDP Да Linux, MS Windows Linux, MS Windows, MAC OSX, iOS

NTP Да Linux Linux, MS Windows, MAC OSX, iOS

DNS, DNS64 Да Linux Linux, MS Windows, MAC OSX, iOS

Proxy Да

(Squid) IPv6 <—> IPv4 Linux Linux, MS Windows, MAC OSX, iOS

NAT64 Да IOS Cisco, Linux Linux, MS Windows, MAC OSX, iOS

OSPF Да IOS Cisco, Linux Linux

BGP Да IOS Cisco -

ND RA Да IOS Cisco Linux, MS Windows, MAC OSX, iOS

DHCP+DNS Да IOS Cisco Linux, MS Windows, MAC OSX, iOS

Ыайеп е1 а1. 2007). Для данных клиентов необходимо также настроить ЭЫБ-сервер с функцией ОЫБ64, который, получая от них запросы, выдаст адреса внешних ресурсов с преобразованием 1Р-заголовка. В противном случае ОС клиента выдаст сообщение о недоступности ресурса. В случае же небольшого числа клиентов их можно просто зарегистрировать на сервере для терминального доступа к внешним ресурсам.

6. МОНИТОРИНГ И УПРАВЛЕНИЕ

В настоящее время сетевое оборудование ведущих производителей адаптировано для управления и мониторинга в сетях 1Ру6. Некоторую проблему могут представлять только устаревшие коммутаторы или БОИО WiFi-маршрутизаторы. Первые просто «прозрачны» для 1Ру6, а последние также доступны для серверов с двойным стеком

IP. В любом случае неадаптированные устройства постепенно выводятся из эксплуатации. В качестве программного средства мониторинга в обсерватории используются пакеты mrtg (Oetiker 2017) и nagios (Galstad 2018). Оба могут работать с IPv6 — сетевыми агентами. Только в настройках nagios в качестве «тестера» доступности и работоспособности сетевого агента следует заменить программу посылки ICMP пакетов — ping на ping6, аналогичную для IPv6. Фрагмент вебстра-нички с сервера мониторинга сети САО отображен на рис. A.2.

В локальных сетях, типа кампусных, потенциально могут возникать проблемы внутренних атак. В таких случаях важно вести мониторинг со сбором статистики подключаемых узлов и их идентификацией. Один из способов реализации этих средств, позволяющий накопить в базе данных и визуали-

sfinx.sao.nj/nagios/cgi-bin/statusmap.cgi7hQst.. .Ь = 1000&ргох1т11у_Ье1дИ1 = 800&1ауеггпос1е=ехс1ис1е

Рис. А.2. Вебстраничка системы мониторинга сети САО РАН. Курсор указывает на коммутатор с 1Ру6.

зировать результаты, описан в работе Gregor et al. (2011).

Собственно управление сетью существенно упрощается при переходе на IPv6. В основном оно складывается из трех частей: назначение IP-адреса сетевому устройству, настройка маршрутизации и фильтрации пакетов в сегментах сети и регистрация, то есть назначение имен устройств в DNS. Первая часть полностью автоматическая, вторая выполняется не чаще, чем меняется архитектура сети или коммутатор. Последняя — только по запросу, при установке нового сервера и, в принципе, тоже может быть автоматизирована при внедрении саморегистрации на административном web-сервере.

7. ВЫВОДЫ

Исходя из полученного опыта по настройке, тестированию и сопровождению сетевого оборудования обсерватории, можно сделать вывод о целесообразности внедрения 1Ру6 в практику эксплуатации наблюдательных инструментов и рабочих мест астрономов. Использование современных сетевых решений, в том числе основанных на 1Ру6, снижает затраты на обслуживание и повышает оперативность подключения новых пользовательских компьютеров. Сетевой компьютер или прибор может без специального административного сопровождения переподключен между портами коммутаторов различных помещений с гарантированным сетевым доступом в режиме 24x7. Результаты тестирования по использованию технологических решений, основанных на 1Ру6, показали как таким образом

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

БЛАГОДАРНОСТИ

Автор благодарит В. В. Витковского и А. А. Иванова за предоставление возможности провести исследования с помощью штатного и нового сетевого оборудования обсерватории.

КОНФЛИКТ ИНТЕРЕСОВ

Автор заявляет об отсутствии конфликта интересов.

СПИСОК ЛИТЕРАТУРЫ

1. J. Abley, Resource Records for EUI-48 and EUI-

64 Addresses in the DNS (2013), https://tools. ietf.org/html/rfc7043.

2. B. Carpenter and K. Moore, Connection of IPv6

Domains via IPv4 Clouds (2001), https://www. ietf.org/rfc/rfc3056.txt.

3. V. N. Chernenkov and V. S. Shergin, in XXV Radio-

Astronomy Conference (Pushchino Research Center of the Russian Academy of Sciences, Pushchino, 1993) pp. 236-237.

4. V. N. Chernenkov, V. V. Vitkovskii, O. P. Zhelenkova,

and S. V. Pavlov, in «Mathematics. Computer. Education», 8, edited by G. Yu. Reznichenko (Progress-Traditsiya, Moscow, 2001), pp. 160-163.

5. Cisco Systems, Catalyst 3750 Software

Configuration Guide, Release 12.2(55)SE (2016), https://www.cisco.com/c/en/us/td/docs/ switches/lan/catalyst3750/software/release/ 12-2_55_se/configuration/guide/scg3750. html?dtid=osscdc000283

6. R. Coltun, D. Ferguson, J. Moy and A. Lindem, OSPF

for IPv6 (2008), https://tools.ietf.org/html/ rfc5340.

7. S. Deeringand R. Hinden, Internet Protocol, Version 6

(IPv6) Specification (1998), https://tools.ietf. org/html/rfc2460.

8. E. Galstad, Nagios Core 4.x (2018), https://www.

nagios.org/.

9. Google, «IPv6» Google Statistics (2015), http://

www.google.com/ipv6/statistics.html.

10. M. Gregor, P. Matousek, T. Podermanski, and M. Sveda, Practical IPv6 Monitoring on Campus (2011), https://services.geant.net/sites/ cbp/knowledge_base/network_monitoring/ documents/gn3-na3-t4-cbpd132.pdf.

11. N. Lutchansky, TAYGA, a stateless NAT64 implementation for Linux (2011), http: //www.litech.org/tayga/.

12. Microsoft Windows Support, Resolving Internet connectivity issues after World IPv6 Launch (2012), https://support. microsoft.com/en-us/help/2533454/ resolving-internet-connectivity-issues-after-world-ipv6-launch-june-6.

13. T. Narten, R. Draves and S. Krishnan, Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (2007), https: //tools.ietf.org/html/rfc4941.

14. E. Nordmark and R. Gilligan, Basic Transition Mechanisms for IPv6 Hosts and Routers (2005), https://tools.ietf.org/html/rfc4213.

15. T. Oetiker, MRTG—TheMulti Router Traffic Grapher (2017), https://oss.oetiker.ch/mrtg/.

16. E. Opredelennov, NAT64 setup using tayga

(2016), https://packetpushers.net/ nat64-setup-using-tayga.

17. V. V. Vlasyuk, SAO RAS Director's Annual Report

(2017), http://www.sao.ru/Doc-k8/Science/ reportUS/2017.pdf.

ИНТЕРНЕТ-ПРОТОКОЛ IPv6 ДЛЯ РАЗВИТИЯ СЕТИ САО РАН 85

ПРИЛОЖЕНИЕ. УПОМЯНУТЫЕ СОКРАЩЕНИЯ И ТЕРМИНЫ

ARP Address Resolution Protocol

BGP Border Gateway Protocol

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DNS64 Domain Name System with NAT64 address translation

ICMP Internet Control Message Protocol

IMAP Internet Message Access Protocol

FTP File Transport Protocol

HTTP HyperText Transfer Protocol for Web Service on Internet

MAC Medium Access Control

NAT Network Address Translation

NAT64 Network Address Translation IPv6 to IPv4 for local address pool

ND RA Neighbour Discovery and Router Advertisment

NFS Network File System

NNTP Network News Transfer Protocol

NTP Network Time Protocol

OSPF Open Shorter Path First routing protocol

POP Post Office Protocol

SAMBA SMB/CIFS Network File System and Remote Control

SLAAC StatLess Address AutoConfiguration

SMTP Simple Mail Transfer Protocol

SOHO Small office/home office

SSH Security Shell

RDP Remote Desktop Protocol

WiFi Wireless Fidelity

X11 MITX11 Window

IPv6 for the Evolution of the Network of the Special Astrophysical Observatory of the

Russian Academy of Sciences

V. N. Chernenkov

Requirements to a modern computer network of a research organization, in particular, to the local-area network of the Special Astrophysical Observatory of the Russian Academy of Sciences (SAO RAS) are described. The choice of the direction of the development of primary tools for supporting the observing process and based on local network infrastructure services of SAO RAS is defined. This will make it easier to automate the administration of the network, prevent the effect of human factor on its reliability, and facilitate its maintenance. The low-rank structure of the network based on high-performance Ethernet commutators is justified. The viability of the use of the sixths-series IPv6 protocols instead of or in addition to IPv4 protocols for mostly unmanned network administration minimizing errors of manual mode. An evolution of a multiplatform network using promising IPv6-supported technologies ensuring implementation of a practically self-tuning configuration. The methods of a client-server implementation of the main network services of the observatory are described.

Keywords: miscellaneous