Кто обладает всем, тот ничем не наслаждается

Задание дочери по рисованию в 5 классе: «Нарисовать инопланетянина». ...

Facebook открыл код платформы Detectron для распознавания объектов на фотографиях
Tue, 23 Jan 2018 10:12:25 +0600

Линус Торвальдс жестко раскритиковал связанные с микрокодом патчи Intel
Mon, 22 Jan 2018 19:47:37 +0600

Red Hat отменил обновление микрокода с устранением уязвимости Spectre
Sat, 20 Jan 2018 10:44:48 +0600

Проект OpenSSL переносит обсуждение разработки из списка рассылки на GitHub
Sat, 20 Jan 2018 10:15:02 +0600

В Firefox 58 появится новый двухуровневый компилятор
Thu, 18 Jan 2018 12:19:16 +0600

Google переводит рабочие станции инженеров с Goobuntu (Ubuntu) на gLinux (Debian)
Thu, 18 Jan 2018 10:05:24 +0600

В systemd 237 запланирована поддержка VPN WireGuard
Thu, 18 Jan 2018 04:31:11 +0600

Verizon стал платиновым участником Linux Foundation и присоединился к разработке ONAP
Wed, 17 Jan 2018 11:43:17 +0600

Mozilla обратилась в суд для защиты сетевого нейтралитета
Wed, 17 Jan 2018 10:26:01 +0600

Новые Web API в Firefox будут доступны только для HTTPS
Tue, 16 Jan 2018 10:50:31 +0600

Обновление микрокода Intel приводит к перезагрузкам систем с CPU Broadwell и Haswell
Mon, 15 Jan 2018 07:17:58 +0600

В Firefox тестируют механизм ускорения навигации по вкладкам
Sun, 14 Jan 2018 22:21:23 +0600

В Firefox 59 будет прекращена поддержка GTK+ 2
Sat, 13 Jan 2018 23:51:01 +0600

Компания Apple присоединилась к альянсу, развивающему свободный видеокодек
Thu, 11 Jan 2018 11:56:35 +0600

Ошибка в обновлении ядра в Ubuntu 16.04 приводит к сбою загрузки системы
Wed, 10 Jan 2018 23:08:11 +0600

Протоколы Расширения Сети Безопасность Почта
RFC 768RFC 791RFC 792RFC 793RFC 903RFC 1157RFC 4302

В этом документе описывается метод, позволяющий станциям динамически определять свой адрес протокольного уровня (например, IP) по известному аппаратному адресу.

Документ содержит спецификацию стандарта, предложенного сообществу ARPA Internet и является приглашением к дискуссии в целях развития стандарта.

Хосты типа бездисковых станций зачастую не знают свой протокольный адрес в момент загрузки, но им обычно известен аппаратный адрес сетевого интерфейса. Для взаимодействия с протоколами вышележащих уровней (например, IP) хост должен узнать свой протокольный адрес из некого внешнего источника. Проблема заключается в отсутствии стандартного механизма получения адреса.

Разработанный Пламмером (Plummer) протокол ARP [1] предназначен для решения обратной задачи — определения аппаратного адреса хоста по его протокольному адресу. В данном документе описывается протокол обратного преобразования адресов RARP. Как м в случае ARP, предполагается широковещательная сетевая среда, подобная Ethernet.

Ниже приведены рекомендации по реализации протокола RARP.

  • Преобразования ARP и RARP отличаются одно от другого. ARP предполагает, что каждый хост знает связь между своими аппаратными протокольными адресами. Информация о связях между аппаратными и протокольными адресами других хостов собирается в специальном кэше. Все хосты сети с точки зрения ARP имеют одинаковый статус (не требуется деление на серверы и клиентов). Для преобразования RARP требуется один или несколько серверов, поддерживающих базу данных о связях между аппаратными и протокольными адресами хостов и отвечающих на запросы адресов от клиентских хостов.

  • Как было отмечено, преобразование RARP требует наличия серверов, поддерживающих большие базы данных. Нежелательно, а в некоторых случаях просто невозможно поддерживать такие базы данный в ядре операционной системы хостов. Таким образом, большинство реализаций будут требовать того или иного взаимодействия с программой, не входящей в ядро.

  • Для протокола важна простота реализации и минимальное воздействие на существующие программы. Было бы ошибкой предлагать протокол, который потребует модификации программ каждого хоста, независимо от того, будет ли этот протокол использоваться на данном хосте.

  • Желательно использование фрагментов кода существующих программ в целях минимизации усилий по разработке и нижения расходов.

Предлагается выполнять преобразование RARP с помощью отдельного протокола канального уровня. Например, для сред Ethernet пакеты RARP будут иметь значение поля Ethertype (которое будет выделено для этого протокола), отличающееся от ARP. Это будет указывать, что преобразования ARP и RARP различаются фундаментально и поддерживаются хостами по-разному. Воздействие на существующие системы минимально — существующие серверы ARP не будут вводиться в заблуждение пакетами RARP. Этот делает RARP самостоятельным протоколом, который может применяться для отображения аппаратных адресов на адреса любых протоколов вышележащего уровня.

Это приближение обеспечивает простоту реализации клиентской части RARP, но разработка RARP-серверов потребует более значительный усилий. Однако, эти трудности не являются непреодолимыми, как показано в Приложении A, где даны наброски двух вариантов реализации протокола для 4.2BSD Unix.

RARP использует такой же формат пакетов, как протокол ARP, а именно:

ar$hrd  (пространство аппаратных адресов) - 16 битов
ar$pro  (пространство протокольных адресов) - 16 битов
ar$hln  (размер аппаратного адреса) - 8 битов
ar$pln  (размер протокольного адреса) - 8 битов
ar$op   (код операции) - 16 битов
ar$sha  (аппаратный адрес отправителя) - n байтов
ar$spa  (протокольный адрес отправителя) - m байтов
ar$tha  (аппаратный адрес получателя) - n байтов
ar$tpa  (протокольный адрес получателя) - m байтов

Поля ar$hrd, ar$pro, ar$hln и ar$pln имеют такой же смысл, как для протокола ARP (см. [1]).

Предположим, что в качестве аппаратного используется 48-битовый адрес Ethernet, а в качестве протокольного — 32-битовый адрес IP. Нам требуется определить адрес IP, соответствующий известному адресу Ethernet. В этом случае для каждого пакета RARP выполняются равенства ar$hrd = 1 (Ethernet), ar$pro = 2048 (Ethertype для пакетов IP), ar$hln = 6, ar$pln = 4.

Протокол использует два кода операций: 3 (request reverse — запрос обратного преобразования) и 4 (reply reverse — отклик на запрос обратного преобразования). Коды операций 1 и 2 имеют такой же смысл, как указано в [1] — пакеты с такими кодами могут передаваться с использованием обычных программ ARP. Пакеты с любыми другими кодами операций являются ошибочными. Как и ARP, данный протокол не использует пакетов not found (не найдено) или error (ошибка), поскольку серверы RARP не обязаны отвечать на полученные запросы. Отправитель запроса RARP должен задавать для себя время ожидания (timeout) отклика на переданный запрос.

Поля ar$sha, ar$spa, $ar$tha и ar$tpa в пакетах RARP интерпретируются следующим образом:

Для пакетов с кодом операции 3 (request reverse):

ar$sha — аппаратный адрес отправителя пакета.
ar$spa — не определено.
ar$tha — аппаратный адрес получателя.
ar$tpa — не определено.

Для пакетов с кодом операции 4 (reply reverse):

ar$sha — аппаратный адрес отвечающего хоста.
ar$spa — протокольный адрес отвечающего хоста.
ar$tha — аппаратный адрес получателя.
ar$tpa — протокольный адрес получатель (то, что было запрошено).

  • [1] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT-LCS, November 1982.

Ниже приведены два наброска различных вариантов реализации сервера RARP для 4.2BSD.

  • Обеспечивается доступ к пакетам канального уровня за пределами ядра. Сервер RARP полностью реализуется за пределами ядра и взаимодействует с ядром только для приема или передачи пакетов RARP. Ядро изменяется так, чтобы обеспечивался требуемый доступ к пакетам RARP; в настоящее время ядро 4.2 обеспечивает доступ только для пакетов IP. Одним из существующих механизмов, которые обеспечивают возможность доступа к пакетам является псевдо-драйвер пакетного фильтра CMU. Этот драйвер успешно используется в CMU и Стэнфорде (Stanford) для реализации подобных серверов в пользовательском пространстве.

  • Создается кэш записей базы данных внутри ядра. Полная база данных сервера RARP поддерживается пользовательским процессом за пределами ядра. Сам сервер RARP реализуется в ядре и использует в откликах содержимое кэша записей. Кэш может быть таким же, какой используется для пересылки ARP. Кэш заполняется записями из базы данных с использованием двух новых операций ioctl (они подобны SIOCIFADDR в том, что реально не связываются с конкретным сокетом). Одна из операций обеспечивает нахождение в «спящем» режиме при отсутствии транзакций, а при появлении запросов передает их пользовательскому процессу, а вторая заносит запись этой транзакции в таблицу ядра. Таким образом, если ядро не может найти запись в кэше, оно помещает запрос в (глобальную) очередь и вызывает функцию wakeup(). Реализация первой операции ioctl включает вызов sleep(), считывание из очереди первого объекта т возврата его пользовательскому процессу. Поскольку ядро не может находится в состоянии ожидания на уровне прерывания, пока пользовательский процесс ответит, оно может отказаться от обработки запроса (в предположении, что клиент повторит запрос) или, если вторая операция ioctl передаст копию запроса обратно в ядро, сформировать и передать отклик на этот запрос.

Николай Малых, moc.milib@hkylamn

НОВОСТИ: Red Hat отменил обновление микрокода с устранением уязвимости Sp ... Sat, 20 Jan 2018 10:44:48 +0600

Компания Red Hat отозвала обновление пакетов с микрокодом (microcode_ctl и linux-firmware), выпущенное 16 января для устранения второго варианта уязвимости Spectre (CVE-2017-5715). В качестве причины отмены обновления называются проблемы со стабильностью, которые были выявлены в результате дополнительного тестирования и жалоб клиентов. На некоторых системах обновление микрокода приводило к невозможности загрузки.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome