Старики видят меньше, но смотрят дальше.

- Девушка , Ваши документы ? ...

За последние две недели компания Mozilla заблокировала 197 дополнений к Firefox
Sun, 26 Jan 2020 10:17:41 +0300

Выпуск дистрибутива Solus 4.1, развивающего рабочий стол Budgie
Sun, 26 Jan 2020 08:51:24 +0300

Выпуск композитного сервера Weston 8.0
Sat, 25 Jan 2020 11:21:54 +0300

Выпуск проекта DXVK 1.5.2 с реализацией Direct3D 9/10/11 поверх API Vulkan
Sat, 25 Jan 2020 09:14:18 +0300

Проект Geneva развивает движок для автоматизации обхода цензурирования трафика
Fri, 24 Jan 2020 22:59:26 +0300

Критические уязвимости в медицинских приборах для мониторинга состояния пациентов
Fri, 24 Jan 2020 10:17:44 +0300

7 уязвимостей в системе управления контентом Plone
Fri, 24 Jan 2020 10:08:42 +0300

Выпуск GNU Mes 0.22, инструментария для самодостаточной сборки дистрибутивов
Fri, 24 Jan 2020 09:44:35 +0300

SystemE, шуточная замена systemd на Emacs Lisp
Fri, 24 Jan 2020 08:23:05 +0300

Обновление ОС Qubes 4.0.3, использующей виртуализацию для изоляции приложений
Thu, 23 Jan 2020 20:33:36 +0300

Выпуск пользовательского окружения Sway 1.4, использующего Wayland
Thu, 23 Jan 2020 12:40:15 +0300

Релиз СУБД SQLite 3.31 с поддержкой генерируемых столбцов
Thu, 23 Jan 2020 10:26:27 +0300

Доступна сборка Android-x86 9.0-rc2
Thu, 23 Jan 2020 10:06:04 +0300

Google продлил до 8 лет время поддержи устройств на базе ChromeOS
Thu, 23 Jan 2020 09:54:13 +0300

Intel выпустил движок распределённой трассировки лучей OSPRay 2.0
Thu, 23 Jan 2020 08:12:07 +0300

Выпуск GhostBSD 20.01
Wed, 22 Jan 2020 22:52:30 +0300

Доступен GameMode 1.5, оптимизатор производительности игр в Linux
Wed, 22 Jan 2020 21:25:43 +0300

Новая версия встраиваемого JavaScript-движка от основателя QEMU и FFmpeg
Wed, 22 Jan 2020 18:10:27 +0300

Выпуск nginx 1.17.8 и njs 0.3.8
Wed, 22 Jan 2020 14:54:50 +0300

Открыт код клиентских приложений ProtonVPN
Wed, 22 Jan 2020 10:44:18 +0300

Технический комитет OASIS утвердил спецификацию OpenDocument 1.3
Wed, 22 Jan 2020 10:03:53 +0300

Дистрибутив Kubuntu начал распространение ноутбука Kubuntu Focus
Wed, 22 Jan 2020 08:38:45 +0300

Для Btrfs представлена асинхронная реализация DISCARD
Wed, 22 Jan 2020 04:48:18 +0300

Стабильный релиз Wine 5.0
Tue, 21 Jan 2020 23:14:20 +0300

Сanonical предложил Anbox Cloud, облачную платформу для запуска Android-приложений
Tue, 21 Jan 2020 14:37:47 +0300

Red Hat развивает JIT-компилятор MIR
Tue, 21 Jan 2020 08:48:56 +0300

Samsung предложил новый вариант драйвера exFAT для ядра Linux
Tue, 21 Jan 2020 08:01:58 +0300

Обновление Firefox 72.0.2. В Firefox 74 появится возможность запрета открепления вкладок
Mon, 20 Jan 2020 22:23:21 +0300

Rust-фреймворк actix-web возрождён и будет передан сообществу
Mon, 20 Jan 2020 21:36:52 +0300

Выпуск файлового менеджера Midnight Commander 4.8.24
Mon, 20 Jan 2020 21:17:09 +0300

В Минэкономики РФ предложили создать архив кода, дублирующий GitHub
Mon, 20 Jan 2020 19:05:46 +0300

Сотрудник Red Hat представил сборочную систему Goals. Выпуск GNU Make 4.3
Mon, 20 Jan 2020 10:18:42 +0300

Первый релиз wZD 1.0.0, сервера компактного хранения мелких файлов
Sun, 19 Jan 2020 14:29:36 +0300

Выпуск платформы совместной разработки OneDev 3.0
Sun, 19 Jan 2020 10:34:21 +0300

Доступны мобильные браузеры Firefox Lite 2.1 и Firefox Preview 3.1.0
Sun, 19 Jan 2020 09:39:11 +0300

Копилефт лицензии постепенно вытесняются пермиссивными
Sat, 18 Jan 2020 22:55:51 +0300

Бета-выпуск интегрированного набора интернет-приложений SeaMonkey 2.53
Sat, 18 Jan 2020 22:07:53 +0300

Разработчик Rust-фреймворка actix-web удалил репозиторий из-за травли
Sat, 18 Jan 2020 20:17:10 +0300

Критические уязвимости в WordPress-плагинах, имеющих более 400 тысяч установок
Sat, 18 Jan 2020 12:26:09 +0300

Представлена платформа Nextcloud Hub для организации совместной работы
Sat, 18 Jan 2020 10:33:49 +0300

IP v4 IP v6
IP v6 - следующий протокол

Хотя системы адресации CIDR и NAT и могут помочь нынешнему IP продержаться еще какое-то время, скорее всего, дни IPv4 сочтены. Помимо прочих технических проблем, имеется одна, угрожающе вырастающая на горизонте. До недавних пор Интернетом пользовались в основном университеты, высокотехнологичные предприятия и правительственные организации в США. С лавинообразным ростом интереса к Интернету, начавшимся в середине 90-х годов, в третьем тысячелетии, скорее всего, им будет пользоваться гораздо большее количество пользователей с принципиально разными требованиями.

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

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

Предвидя появление этих проблем, проблемная группа проектирования Интернета IETF начала в 1990 году работу над новой версией протокола IP, в которой никогда не должна возникнуть проблема нехватки адресов, а также будут решены многие другие проблемы. Кроме того, новая версия протокола должна была быть более гибкой и эффективной. Были сформулированы следующие основные цели:

1. Поддержка миллиардов хостов даже при неэффективном использовании адресного пространства.

2. Уменьшение размера таблиц маршрутизации.

3. Упрощение протокола для ускорения обработки пакетов маршрутизаторами.

4. Более надежное обеспечение безопасности (аутентификации и конфиденциальности), чем в нынешнем варианте IP.

5. Необходимость обращать больше внимания на тип сервиса, в частности, при передаче данных реального времени.

6. Упрощение работы многоадресных рассылок с помощью указания областей рассылки.

7. Возможность изменения положения хоста без необходимости изменять его адрес.

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

9. Возможность сосуществования старого и нового протоколов в течение нескольких лет.

Чтобы найти протокол, удовлетворяющий всем этим требованиям, IETF издал в RFC 1550 приглашение к дискуссиям и предложениям. Был получен двадцать один ответ. Далеко не все варианты содержали предложения, полностью удовлетворяющие этим требованиям. В декабре 1992 года были рассмотрены семь серьезных предложений. Их содержание варьировалось от небольших изменений в протоколе IP до полного отказа от него и замены совершенно другим протоколом.

Одно из предложений состояло в использовании вместо IP протокола CLNP, который с его 160-разрядным адресом обеспечивал бы достаточное адресное пространство на веки вечные. Кроме того, это решение объединило бы два основных сетевых протокола. Однако все же сочли, что при подобном выборе придется признать, что кое-что в мире OSI было сделано правильно, что было бы политически некорректным в интернет-кругах. Протокол CLNP, на самом деле, очень мало отличается от протокола IP. Окончательный выбор был сделан в пользу протокола, отличающегося от IP значительно сильнее, нежели CLNP. Еще одним аргументом против CLNP была его слабая поддержка типа сервиса, требовавшегося для эффективной передачи мультимедиа.

Три лучших предложения были опубликованы в журнале IEEE Network Magazine (Deering, 1993; Francis, 1993; Katz и Ford, 1993). После долгих обсуждений, переработок и борьбы за первое место была выбрана модифицированная комбинированная версия Диринга (Deering) и Фрэнсиса (Francis), называемая в настоящий момент протоколом SIPP (Simple Internet Protocol Plus — простой интернет-протокол Плюс). Новому протоколу было дано обозначение IPv6 (протокол IPv5 уже использовался в качестве экспериментального протокола потоков реального времени).

Протокол IPv6 прекрасно справляется с поставленными задачами. Он обладает достоинствами протокола IP и лишен некоторых его недостатков (либо они проявляются в меньшей степени), к тому же наделен некоторыми новыми особенностями. В общем случае протокол IPv6 несовместим с протоколом IPv4, но зато совместим со всеми остальными протоколами Интернета, включая TCP, UDP, IСМР, IGMP, OSPF, BGP и DNS, для чего иногда требуются небольшие изменения (в основном чтобы работать с более длинными адресами). Основные особенности протокола IPv6 обсуждаются далее. Дополнительные сведения о нем можно найти в RFC с 2460 по 2466.

Прежде всего, у протокола IPv6 поля адресов длиннее, чем у IPv4. Они имеют длину 16 байт, что решает основную проблему, поставленную при разработке протокола, — обеспечить практически неограниченный запас интернет-адресов. Мы еще кратко упомянем об адресах чуть позднее.

Второе заметное улучшение протокола IPv6 по сравнению с IPv4 состоит в более простом заголовке пакета. Он состоит всего из 7 полей (вместо 13 у протокола IPv4). Таким образом, маршрутизаторы могут быстрее обрабатывать пакеты, что повышает производительность. Краткое описание заголовков будет приведено далее.

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

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

Наконец, в новом протоколе было уделено больше внимания типу предоставляемых услуг. Для этой цели в заголовке пакета IPv4 было отведено 8-разрядное поле (на практике не используемое), но при ожидаемом росте мультимедийного трафика в будущем требовалось значительно больше разрядов.

Основной заголовок IPv6

Заголовок IPv6 показан схематично приведен ниже. Поле Версия содержит число 6 для IPv6 (и 4 для IPv4). На период перехода с IPv4 на IPv6, маршрутизаторы по значению этого поля смогут различать пакеты нового и старого стандарта. Подобная проверка потребует нескольких тактов процессора, что может оказаться нежелательным в некоторых ситуациях, поэтому многие реализации, вероятно, попытаются избежать этих накладных расходов и будут отличать пакеты IPv4 от пакетов IPv6 с помощью некоторого поля в заголовке уровня передачи данных. При этом пакеты будут передаваться напрямую нужному сетевому уровню. Однако знакомство уровня передачи данных с типами пакетов сетевого уровня полностью нарушает принцип разделения протоколов на уровни, при котором каждый уровень не должен знать назначения битов из пакетов более высокого уровня. Дискуссия между лагерями, руководствующимися принципами «Делай правильно» и «Делай быстро», несомненно, будет долгой и энергичной.

Поле Класс трафика используется для того, чтобы различать пакеты с разными требованиями к доставке в реальном времени. Такое поле присутствовало в стандарте IP с самого начала, однако оно реально обрабатывалось маршрутизаторами лишь в единичных случаях. Сейчас проводятся эксперименты, направленные на то, чтобы определить, как лучше всего использовать это поле для передачи данных в реальном времени.

Поле Метка потока также пока является экспериментальным, но будет применяться для установки между отправителем и получателем псевдосоединения с определенными свойствами и требованиями. Например, поток пакетов между двумя процессами на разных хостах может обладать строгими требованиями к задержкам, что потребует резервирования пропускной способности. Поток устанавливается заранее и получает идентификатор. Когда прибывает пакет с отличным от нуля содержимым поля Метка потока, все маршрутизаторы смотрят в свои таблицы, чтобы определить, какого рода особая обработка ему требуется.

Таким образом, новый протокол пытается соединить достоинства подсетей различных типов: гибкость дейтаграмм и гарантии виртуальных каналов.

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

Ноле Длина полезной нагрузки сообщает, сколько байт следует за 40-байтовым заголовком. В заголовке IPv4 аналогичное поле называлось Полная длина и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно.

Поле Следующий заголовок раскрывает секрет возможности использования упрощенного заголовка. Дело в том, что после обычного 40-байтового заголовка могут идти дополнительные (необязательные) расширенные заголовки. Это поле сообщает, какой из шести дополнительных заголовков (на текущий момент) следует за основным. В последнем IP-заголовке поле Следующий заголовок сообщает, какой обрабатывающей программе протокола транспортного уровня (то есть TCP или UDP) передать пакет.

Поле Максимальное число транзитных участков не дает пакетам вечно блуждать по сети. Оно имеет практически то же назначение, что и поле Время жизни з заголовке протокола IPv4. Это поле уменьшается на единицу на каждом транзитном участке. Теоретически, в протоколе IPv4 это поле должно было содержать секунды времени жизни пакета, однако ни один маршрутизатор не использовал его подобным образом, поэтому имя поля было приведено в соответствие способу его применения.

Следом идут поля Адрес отправителя и Адрес получателя. В исходном предложении Диринга (протоколе SIPP) использовались 8-байтовые адреса, но при рассмотрении проекта было решено, что 8-байтовых адресов хватит лишь на несколько десятилетий, в то время как 16-байтовых адресов должно хватить навечно. Другие возражали, что 16 байтов для адресов слишком много, тогда как третьи настаивали на 20-байтных адресах для совместимости с дейтаграммным протоколом OSI. Еще одна фракция ратовала за адреса переменной длины. После продолжительных споров было решено, что наилучшим компромиссным решением являются 16-байтовые адреса фиксированной длины.

Для написания 16-байтовых адресов была выработана новая нотация. Адреса в IPv6 записываются в виде восьми групп по четыре шестнадцатеричных цифры, разделенных двоеточиями, например:

8000:0000:0000:0000:0123:4567:89AB:CDEF

Поскольку многие адреса будут содержать большое количество нулей, были разрешены три метода сокращенной записи адресов. Во-первых, могут быть опущены ведущие нули в каждой группе, например, 0123 можно записывать как 123. Во-вторых, одна или более групп, полностью состоящих из нулей, могут заме­няться парой двоеточий. Таким образом, приведенный выше адрес принимает вид

8000::123:4567:89AB:CDEF

Наконец, адреса IPv4 могут записываться как пара двоеточий, после которой пишется адрес в старом десятичном формате, например:

::192.31.20.46

Возможно, нет необходимости говорить об этом столь подробно, но количество всех возможных 16-байтовых адресов очень велико - 2 в 128 степени, что приблизительно равно 3 x10 в 38 степени. Если покрыть компьютерами всю планету, включая сушу и океаны, то протокол IPv6 позволит иметь около 7x10 в 23 степени IP-адресов на квадратный метр. Кто изучал химию, может заметить, что это число больше числа Авогадро. Хотя в планы разработчиков не входило предоставление собственного IP-адреса каждой молекуле на поверхности Земли, они оказались не так уж далеко от обеспечения такой услуги.

На практике не все адресное пространство используется эффективно, как, например, не используются абсолютно все комбинации телефонных номеров. Например, телефонные номера Манхэттена (код 212) почти полностью заняты, тогда как в штате Вайоминг (код 307) они почти не используются. В RFC 3194 Дьюранд (Durand) и Хуйтема (Huitema) приводят свои вычисления. Утверждается, что если ориентироваться на использование телефонных номеров, то даже при самом пессимистическом сценарии все равно получается более 1000 IP-адресов на квадратный метр поверхности Земли (включая как сушу, так и море)

При любом более вероятном сценарии обеспечиваются триллионы адресов на квадратный метр. Таким образом, маловероятно, что в обозримом будущем обнаружится нехватка адресов. Также следует отметить, что на сегодня только для 28 % адресного пространства придуманы применения. Остальные 72 % зарезервированы на будущее.

Полезно сравнить заголовок IPv4 с заголовком IPv6 , чтобы увидеть, что осталось от старого стандарта. Поле IHL исчезло, так как заголовок IPv6 имеет фиксированную длину. Поле Протокол также было убрано, поскольку поле Следующий заголовок сообщает, что следует за последним IP-заголовком (то есть UDP- или ТСР-сегмент).

Были удалены все поля, относящиеся к фрагментации, так как в протоколе IPv6 используется другой подход к фрагментации.

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

Во-вторых, минимальный размер пакета был увеличен с 576 до 1280, чтобы можно было передавать 1024 байт данных, плюс множество заголовков. Кроме того, когда хост посылает слишком большой IРv6-пакет вместо того, чтобы его фрагментировать, то маршрутизатор, не способный переслать пакет дальше, посылает обратно сообление об ошибке. Получив это сообщение, хост должен прекратить всю передачу этому адресату. Гораздо правильнее будет научить все хосты посылать пакеты требуемого размера, нежели учить маршрутизаторы фрагментировать их на лету.

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

Дополнительные заголовки

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

Дополнительные заголовки IPv6

Дополнительный заголовок

Описание

Параметры маршрутизации

Разнообразная информация для маршрутизаторов

Параметры получателя

Дополнительная информация для получателя

Маршрутизация

Частичный список транзитных маршрутизаторов на пути пакета

Фрагментация

Управление фрагментами дейтаграмм

Аутентификация

Проверка подлинности отправителя

Шифрованные данные

Информация о зашифрованном содержимом

У некоторых заголовков формат фиксированный, другие содержат переменное количество полей переменной длины. Для них каждый пункт кодируется в виде тройки (Тип, Длина, Значение). Тип представляет собой однобайтовое поле, содержащее код параметра. Первые два бита этого поля сообщают, что делать с пакетом, маршрутизаторам, не знающим, как обрабатывать данный параметр. Возможны четыре следующих варианта: пропустить параметр, игнорировать пакет, игнорировать пакет и отослать обратно ICMP-пакет, а также то же самое, что и предыдущий вариант, но не отсылать обратно ICMP-пакет в случае многоадресной рассылки (чтобы один неверный многоадресный пакет не породил миллионы ICMP-донесений).

Поле Длина также имеет размер 1 байт. Оно сообщает, насколько велико значение (от 0 до 255 байт). Поле Значение содержит необходимую информацию, размером до 255 байт.

Заголовок параметров маршрутизации содержит информацию, которую должны исследовать маршрутизаторы на протяжении всего пути следования пакета. Пока что был определен один вариант использования этого параметра: поддержка дейтаграмм, превышающих 64 Кбайт. Формат заголовка показан на схеме:

Как и все дополнительные заголовки, он начинается с байта, означающего тип следующего заголовка. Следующий байт содержит длину дополнительного заголовка в байтах, не считая первых 8 байт, являющихся обязательными. С этого начинаются все расширения.

Следующие два байта указывают, что данный параметр содержит размер дейтаграммы (код 194) в виде 4-байтового числа. Размеры меньше 65 536 не допускаются, так как могут привести к тому, что первый же маршрутизатор проигнорирует данный пакет и отошлет обратно ICMP-сообщение об ошибке. Дейтаграммы, использующие подобные расширения заголовка, называются джамбограммами (от слова «jumbo», означающего нечто большое и неуклюжее). Использование джамбограмм важно для суперкомпьютерных приложений, которым необходимо эффективно передавать по Интернету гигабайты данных.

Маршрутный заголовок содержит информацию об одном или нескольких маршрутизаторах, которые следует посетить по пути к получателю. Это очень сильно напоминает свободную маршрутизацию стандарта IPv4 тем, что указанные в списке маршрутизаторы должны быть пройдены строго по порядку, тогда как не указанные проходятся между ними. Формат маршрутного заголовка показан ниже:

Первые четыре байта дополнительного маршрутного заголовка содержат четыре однобайтовых целых числа. Поля Следующий заголовок и Длина дополнительного заголовка были описаны ранее. В поле Тип маршрутизации описывается формат оставшейся части заголовка. Если он равен 0, это означает, что далее следует зарезервированное 32-разрядное слово, а за ним — некоторое число адресов IPv6. В будущем, возможно, будут по мере необходимости изобретаться какието новые поля. Наконец, в поле Число оставшихся сегментов указывается, сколько адресов из списка еще осталось посетить. Его значение уменьшается при прохождении каждого адреса. Когда оно достигает нуля, пакет оставляется на произвол судьбы - никаких указаний относительно его дальнейшего маршрута не дается. Обычно в этот момент пакет уже находится достаточно близко к месту назначения, и оптимальный маршрут очевиден.

Заголовок фрагментации определяет фрагментацию способом, схожим с протоколом IPv4. Заголовок содержит идентификатор дейтаграммы, номер фрагмента и бит, информирующий о том, является ли этот фрагмент последним. В отличие от IPv4, в протоколе IPv6 фрагментировать пакет может только хост-источник. Маршрутизаторы фрагментировать пересылаемые пакеты не могут. Это порывающее с философией прошлого изменение в протоколе упрощает и ускоряет работу маршрутизаторов. Как уже было сказано, маршрутизатор отвергает слишком большие пакеты, посылая в ответ ICMP-пакет, указывающий хосту-источнику на необходимость заново передать пакет, выполнив его фрагментацию на меньшие части.

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

НОВОСТИ: Для Btrfs представлена асинхронная реализация DISCARD Wed, 22 Jan 2020 04:48:18 +0300

Для файловой системы btrfs представлена асинхронная реализация операции DISCARD (пометка освобождённых блоков, которые уже можно не хранить физически), реализованная инженерами компании Facebook.

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