Какое сообщение icmpv6 отправляется если поле hop limit ipv6 пакета уменьшается до нуля

Обновлено: 18.05.2024

Пост является кратким конспектом Wiki, TechNet'а, FreeBSD'шного handbook'a, Serverfault'a, множества RFC и документов IANA, а также курсов от Специалист.Ру для сотрудников Яндекса.

Пост можно рассматривать как копилку ссылок по актуальной на 2012 год спецификации IPv6. Однако он никак не описывает возможные способы установки IPv6 соединения с интернетом и не привязан к какой-либо определённой ОС.
Учтите, что прочтение данной хабрастатьи займёт у вас не более получаса, однако крайне рекомендуется ознакомиться со всеми приведёнными в статье ссылками… Последнее может занять несколько недель.

Prerequisites

IPv6 Адреса

Анатомия IPv6 адресов

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

Маски подсетей

Маски теперь задаются только /prefix'ами (CIDR), классовой адресации и стандартной decimal dotted нотации в IPv6 нет. Так же теперь первый и последний адрес сети не являются зарезервированными под идентификатор сети и broadcast соответственно.

Выделение IPv6 адресов

Типы адресов и их префиксы

  • ::/128 - Unspecified — не должен принадлежать ни одной ноде в сети;
  • ::/0 - Default route ;
  • ::1/128 - Loopback ;
  • fe80::/10 - Link-Local — адреса уникальные на линке. Создание IPv6 link-local адреса из префикса fe80:: и MAC адреса сетевой карты, как и многое другое описано в презентации от Microsoft и в документе Introduction to IP Version 6, также процедура создания модифицированного EUI-64 идентификатора на пальцах разъяснена в Приложении А RFC4291);
  • fec0::/10 - Site-Local — устарели судя по RFC3879;
  • fc00::/7 - Unique Site-Local — пришли на замену Site-Local в RFC4193. В данный момент разбит на две части: fc00::/8 и fd00::/8. Уникальные в пределах организации, не роутящиеся в интернет адреса. Однако могут роутиться внутри site'a и между site'ами;
  • ff00::/8 - Multicast — о мультикасте подробнее расскажу чуть ниже. Полный список мультикаст адресов можно посмотреть тут: IANA IPv6 Multicast Addresses;
  • ::0000/96 - IPv4-Compatible IPv6 Address — устарели;
  • ::ffff/96 - IPv4-Mapped IPv6 Address — Адреса предназначенные в основногм для Socket API. Более подробно их назначение описано в RFC4038. Прочтение этого RFC будет полезно программистам которые собираются писать Dual-Stack приложения;

Виды трафика

  • Unicast — Старый добрый юникаст;
  • Multicast — Мультикаст теперь необходимое расширение, а не опциональное как в IPv4. IGMP был заменён на MLD (Multicast Listener Discovery). А процедура получения глобального мультикаст префикса стала тривиальной — теперь при получении /64 префикса провайдер автоматически получает 4.2 миллиарда глобальных мультикаст групп. Процедура подробно описана в RFC3306, а также дополнена внедрением адреса RP прямо в IPv6 адрес в RFC3956. Получение глобального мультикаст префикса для IPv4 и IPv6 описано в RFC6308. Стоит также заметить, что в IPv4 Multicast link-layer префикс был 01:00:5e, в IPv6 он стал 33:33:ff (посмотреть список групп для интерфейсов во FreeBSD можно через ifmcstat или же через ip maddr в Linux);
  • Anycast — Такой же anycast как и в IPv4. Этот тип адреса обычно анонсируется протоколом динамической маршрутизации (например BGP), сразу из нескольких мест. Это обеспечивает оптимальный, с точки зрения протокола маршрутизации, роутинг;
  • Broadcast — в IPv6 broadcast'а не существует. В место него можно использовать All Nodes Address. Пакеты посланные на него будут рассылаться только на хосты с настроенным IPv6 адресом (при включеном MLD snooping'е); Также часть протоколов раньше использовавших Broadcast в IPv6-версии всёже обзавелись собственной multicast группой;

Address Scope

В IPv6 появилось такое понятие как Scope, он же Zone ID терминологии Microsoft. На самом деле оно было и в IPv4, однако не было задано явно: сети 10/8, 172.16/12 и 192.168/16 яркие тому примеры.

В случае Unicast/Anycast адресов приминимо следующее:
У каждого IPv6 enabled интерфейса есть свой Link-local адрес. Его scope, внезапно, local. Эти адреса уникальны в пределах линка, но не обязаны быть актуальными в пределах одного хоста. Так, например, VLAN созданный на интерфейсе будет иметь такой же link-local адрес, что и родительский интерфейс (так как без использования IPv6 Privacy Extensions он будет генериться из тогоже Link Layer адреса). Для того, чтобы явно указать интерфейс которому принадлежит IPv6 адрес нужно или указывать в ручную интерфейс для исходящих пакетов или использовать специальный суффикс при записи адреса: %ИндексИнтерфейса в Windows (fe80::2b0:d0ff:fee9:4143%3) или %ИмяИнтерфейса в *BSD/Linux (fe80::2b0:d0ff:fee9:4143%em0).
В случае Multicast адресов scope указан в последних четырёх битах вторго октета IPv6 адреса: ff0s:: и может быть interface-local, link-local, admin-local, site-local, organization-local или же global.
Дополнительно стоит ознакомиться с RFC4007 IPv6 Scoped Address Architecture

Жизненный цикл IPv6 адреса

Возможны следующие state'ы IPv6 адреса на протяжении его жизненного цикла:

  • Tentative — Адрес ещё проверяется на уникальность;
  • Valid — Траффик на этот адрес будет получатся хостом, делится на 2 подсостояния:
    • Prefered state — Основное состояние, неограниченное использование адреса;
    • Deprecated state — Адрес ещё можно использовать для старых соединений, но нельзя создавать новые соединения;

    IPv6 Пакет

    Заголовок IPv6 пакета

    • Фиксированный размер заголовка;
    • Отсутствует Checksum заголовка, соответственно, его не надо проверять, а также пересчитывать для каждого пакета при изменении TTL Hop Limit. Так как checksum больше нет, то вся ответственность за целостность информации должна лежать на протоколе более низкого уровня, так например у Ethernet фреймов есть свой честный CRC32. Так же у UDP пакетов наличие checksum теперь обязательно и UDP/IPv6 пакеты с Checksum 0000 будут просто отбрасываться принимающим хостом;
    • Сам TTL теперь именуется Hop Limit (скорее всего потому, что раньше одним из условий у роутера было уменьшать TTL на один каждую секунду прибывания пакета в очереди, поэтому и TIME-to-live). В связи с последним трендом с повсеместным введением MPLS/TE стоит заметить, что при прохождении IP-пакета через MPLS облако его TTL/HopLimit может не и меняется;
    • Роутеры теперь не занимаются фрагментацией пакетов. Хосты должны сами проводить Path MTU discovery и разбивать пакеты. Минимальный MTU теперь равен 1280.
    • Были добавлены Метки потоков, служат для разгрузки роутеров, более точной приоритезации трафика и балансировки. Более подробно можно почитать в RFC6437 — IPv6 Flow Label Specification. До сих пор ходят баталии об использовании этого поля IPv6 заголовка на практике. Эпик-треды можно почитать в RFC6294 — Survey of Proposed Use Cases for the IPv6 Flow Label, RFC6436 — Rationale for Update to the IPv6 Flow Label Specification и RFC6438 — Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels. Единственная операционная система(из протестированных нами) которая на выставляет по умолчению flow label'ы это FreeBSD;
    • Изначально(в obsoleted RFC1883) поле Traffic Class называлось Priority и занимало 4 бита, а flow label был 24 бита. В RFC2460 они стали 8 и 20 бит соответственно. Если кому интересна никрофилия можно почитать остальные Historical notes на вики;
    • Поддержка IPSec теперь является обязательной;

    Extension Headers

    • Hop-by-Hop Options — любой роутер на пути следования пакета должен просматривать только IPv6 заголовок, все остальные заголовки предназначены эксклюзивно для получателя пакета. Однако Hop-By-Hop заголовок является исключением — его просматривают все роутеры и если он есть, то должен идти сразу за IPv6 заголовком.
    • Routing — RFC5095 отменяет Type 0 Routing Headers, которые содержат в своём определении DoS уязвимость (ещё серьёзнее нежели source routing в IPv4). Подробнее тема безопасности в IPv6 обсуждается в RFC4942 и в презентации Security Implications of IPv6.
    • Fragment — Заголовок фрагментированного пакета. Как я уже упоминал, роутеры больше не занимаются фрагментацией, так что отправитель сам должен позаботится об оптимальном размере пакета, иначе получит Packet too big от одного из роутеров на пути. Кстати, MTU для работы IPv6 не должен быть менее 1280.
    • Destination Options — Опции предназначенные только получателю.
    • Authentication — RFC4302
    • Encapsulating Security Payload — RFC4303

    IPv6 Протоколы

    ICMPv6

    ICMP в IPv6 был заменён на ICMPv6. О ICMPv6 можно прочитать в RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
    Сам по себе ICMPv6 довольно прост, однако на его основе сделано множество довольно не тривиальных протоколов, о которых мы поговорим чуть ниже.

    MLD

    NDP

    Автоконфигурация

    Zeroconf

    Как уже было упомянуто выше, хосты умеют автоматически генерировать себе IPv6 link-local адрес из адреса канального уровня. Так что без какой либо настройки любой IPv6-enabled хост подключённый к сети выдаёт сам себе адрес сетевого уровня.
    В IPv4 эта технология использует зарезервированный IPv4 диапазон 169.254/16. Подробно технология описана в RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses (Заметьте, что этот RFC вышел после IPv6'ого 2462).

    Stateful

    В IPv4 автоконфигурация возможна только с использованием DHCP сервера. В IPv6 эту возможность оставили: можно конфигурировать сеть с помощью DHCPv6 сервера и клиента. Однако, поддержка со стороны вендоров DHCPv6 пока не блещет, так например, dhclient во FreeBSD из коробки не умеет IPv6.

    Stateless
    • Stateless определение адреса возможно только при наличии роутера/ротеров рассылающего RA;
    • Каждый роутер имеет приоритет: high/medium/low. Операционная система должна его учитывать при выборе default route;
    • RFC6106 — IPv6 Router Advertisement Options for DNS Configuration объясняет как встраивать адреса DNS-серверов прямо в RA, что позволяет избавиться от использования DHCPv6 для этого дела. Однако это поддерживается не всеми вендорами;
    • Генерировать IPv6 адрес используя свой link-layer не очень безопасно с точки зрения privacy. Ваши перемещения по миру а иногда и модель оборудования будет доступна всему интернету. Решение проблемы было описано в RFC4941 — Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Все современные операционные системы поддерживают Privacy Extensions;
    Комбинированая

    Могут использоваться одновременно оба вида автоконфигурации, например stateless для получения IPv6 префикса и stateful для получения адресов DNS-серверов и/или других параметров, которые нельзя передать с помощью Router Advertisement.

    DNS

    Этому моменту в документации по IPv6 уделено достаточно мало внимания, однако судя по количеству RFC на эту тему, изменения колоссальны.
    Для полноценной поддержки IPv6 в DNS систему было введено множество изменений (RFC3152, RFC3226, RFC3363) и всё равно остаётся некоторое количество нерешённых проблем — RFC4472.
    Некоторое время даже существовало два стандарта для описания IPv6 адресов в DNS: A6 и AAAA, плюсы и минусы каждого из них описаны в RFC3364. Если вкратце, то A6 предоставляет большую гибкость и меньшую зависимость зоны от префикса, а AAAA являются лишь частным случаем A6 с длинной префикса 0. A6 в последствии был переведён в статус Experimental в RFC3363 — Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
    Для минимальной поддержки IPv6 требуется только одна AAAA запись. Также может потребоваться наличие PTR записи. Обратные DNS записи для IPv6 выглядят ужасающе. Так, например, обратка для адреса 4321:0:1:2:3:4:567:89ab будет выглядеть как b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA. . Это зрелище не для слабонервных, однако, это скорее всего сподвигнет людей к автоматической генерации обраток. Для ручной генерации я бы рекомендовал sipcalc с ключом -r или что-либо аналогичное.

    Прочее

    Протоколы более высокого уровня

    Часть протоколов, использующих адрес сетевого уровня в своей работе требовали внесения в них определённых изменением для того, чтобы начать работать по IPv6. Ярким примером такого протокола является FTP.

    Тунелирование IPv6 трафика поверх IPv4 сетей

    Mobile IPv6

    Про него не знаю нечего, так что просто оставлю это здесь: Mobile IP.

    IPv6 адрес как хранилище информации

    Согласитесь 128бит — это огромный простор для фантазии. Существует множество технологий которые пытаются использовать эти самые 128бит. От кодирования туда IPv4 адреса и криптографических сигнатур до определения растояний между нодами (тут кстати даже мы думали в этом направлении, но пока присмтриваемся к ALTO: Application-Layer Traffic Optimization (ALTO) Problem Statement).

    Socket API

    Хабратопик описывает IPv6 с точки зрения NOC / системного администратора, но не с точки зрения программиста. Если кому-то интересны особенности программирования под IPv6, то рекомендую обратиться к RFC3493 — Basic Socket Interface Extensions for IPv6 и книжке IPv6 Network Programming

    Послесловие


    Не смотря на все мои попытки всё структурировать статья получилась довольно сумбурной. Возможно это из-за её сугубо теоретической направленности, возможно из-за того что сам ещё не всё устаканил у себя в голове. В любом случае, я надеюсь, она будет служить хорошей памяткой и катологом ссылок по IPv6, как для меня, так и для всего хабрасообщества.
    Однако, возможно, перед тем как зарываться с головой в RFC и tcpdump'ы можно сначала почитать книжки, например, IPv6 Essentials от O'Reilly должна сильно помочь усвоению материала описанного в этой статье.

    Версия 6 протокола Internet Control Message Protocol (ICMPv6) сохраняет многие функции версии 4, но вводит и несколько важных изменений:

    ■ ICMPv6 принимает на себя функции отчета о членстве в многоадресной группе протокола Internet Group Management Protocol.

    ■ ICMPv6 помогает определить выключение маршрутизатора или партнера по коммуникации.

    ICMPv6 настолько отличается от старой версии, что ему присвоен новый номер 58 в заголовке Next Header.

    0 Нет маршрута к точке назначения

    1 Административно запрещено взаимодействие с точкой назначения

    2 Следующее назначение в заголовке Routing не является соседом, но установлен бит strict.

    3 Адрес недоступен

    4 Порт недоступен



    0 Неправильное количество полей заголовка

    1 Нераспознанный тип в поле Next Header

    2 Нераспознанный вариант IPv6

    130 Group Membership Query

    131 Group Membership Report

    132 Group Membership Reduction


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

    Router Discovery Исследование маршрутизаторов. Поиск маршрутизаторов в локальной связи.
    Prefix Discovery Исследование префикса. Исследование и использование префикса точки назначения (на связи или удаленной). Используется вместо маски подсети.
    Parameter Discovery Исследование параметров. Выяснение значений параметров (например, MTU или предела по умолчанию для счетчика попаданий).
    Address Autoconfiguration Автоконфигурация адресов. Самоконфигурация адресов интерфейса связи.
    Address Resolution Разрешение адресов. Отображение IP-адреса соседа по связи на адрес уровня связи данных.
    Next-hop Determination Определение следующего попадания. Отображение IP-адреса на адрес участка следующего попадания.
    Neighbor Unreachability Detection Определение недостижимости соседа. Определение отказавшего соседнего хоста или маршрутизатора.
    Duplicate Address Detection Определение дублирования адресов. Проверка, не используется ли присваиваемый IP-адрес другой системой.
    Redirect Перенаправление. Получение уведомления, что существует лучший маршрутизатор для данной точки назначения или что точка назначения находится в локальной связи.

    Маршрутизаторы предоставляют хостам:

    ■ Адресную информацию маршрутизатора

    ■ Список всех префиксов, используемых связью

    ■ Префиксы, которые должны применять хосты для создания собственных адресов

    ■ Максимальный предел попаданий, который должен использоваться для путей, проходящих через этот маршрутизатор

    ■ Указание, должны ли хосты использовать сервер загрузки для получения дополнительных конфигурационных данных

    ■ MTU для связи, имеющей различные MTU

    ■ Значения для различных таймеров

    ■ Обнаружения дублированных IP-адресов

    ■ Тестирования, является ли маршрутизатор отключенным

    ■ Тестирования, является ли отключенным сосед, которому посылались пакеты

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

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


    ICMPv6 описан в RFC 1885. На момент выхода книги протоколы Neighbor Discovery были еще на стадии обсуждения.

    Итак, каждый пакет IPv6 начинается с заголовка IPv6 (неожиданно, правда?) Но теперь, в отличие от IPv4, все необязательные элементы мы можем перенести из основного заголовка в заголовки расширения. Без каких полей мы абсолютно не сможем обойтись в основном заголовке? Используя наш опыт IPv4, а также не забывая сказанное в §1 и §3.1, составим предварительный неупорядоченный список :

    • версия IP
    • адрес источника
    • адрес назначения;
    • длина пакета;
    • следующий заголовок.

    Теперь давайте рассмотрим подробнее эти поля и, если понадобится, скорректируем их свойства.

    Целочисленные поля, "созданные" нами по ходу нашей работы, будут по умолчанию в беззнаковом коде. Как вы думаете, почему отрицательные и дробные числа редко встречаются в сетевых протоколах?

    Как мы уже обсудили в §1, поле версии IP поможет надежно отличить пакет IPv6 от пакета IPv4 в переходных условиях, пока новая версия будет работать наряду со старой. Учитывая масштабы применения IPv4 и финансовые вложения в технологии на его основе, этот переходный период может растянуться на многие годы. Очевидно, что длина и позиция поля версии обязаны быть такими же, как в заголовке IPv4. То есть длина этого поля — 4 бита, а находится оно в самом начале заголовка (учитывая сетевой порядок битов и байтов). Теперь его новое значение — 6.

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

    Кстати, именно благодаря тому, что адрес источника в пакете IP не бывает групповым, мы можем говорить о типе всего пакета в зависимости от типа его адреса назначения, как то "индивидуальный пакет" и "групповой пакет".

    Без поля TTL или аналогичного ему возникает риск бесконечного зацикливания пакетов в сети. При неудачном стечении обстоятельств это может также сопровождаться дублированием пакетов, что означает экспоненциальный рост паразитного трафика и полный крах сети. Так что без эквивалента TTL нам никак не обойтись. Однако, перенося поле TTL в заголовок IPv6, мы внесем в его свойства долгожданную поправку. Как показал опыт работы с IPv4 [§5.3.1 RFC 1812], измерить время удержания транзитного пакета на узле затруднительно и, к тому же, оно редко превышает одну секунду. Де-факто поле TTL ведет обратный отсчет не секунд жизни пакета, а его шагов по транзитным узлам. Мы не можем не учесть этот опыт в IPv6, и нам остается только переименовать поле сообразно его функции: "предельное число шагов" (Hop Limit). Длина его по -прежнему будет 8 бит . По смыслу это поле не может быть дробным или отрицательным, поэтому оно целое беззнаковое.

    По первоначальному замыслу, поле TTL в IPv4 отсчитывало именно время, а не шаги, чтобы заодно управлять интервалами таймеров на узле назначения. Так, в первом эталонном алгоритме сборки пакета IPv4 из фрагментов интервал таймера сборки был функцией от остаточного значения TTL [§3.2 RFC 791]. Однако впоследствии от этого подхода отказались в пользу других методов. В частности, значение тайм-аута сборки стало постоянным [§3.3.2 RFC 1122].

    Правила работы с полем "предельное число шагов" [§3 RFC 2460] не отличаются от общепринятой практики IPv4:

    • источник пакета помещает в это поле начальное значение, выбранное по своему усмотрению;
    • каждый транзитный узел уменьшает значение этого поля на единицу и, если оно упало до нуля, уничтожает пакет и, возможно, шлет источнику аналог извещения ICMP;

    конечный адресат пакета игнорирует это поле.

    В каких комментариях нуждаются эти простые требования?

    Эталонная реализация IPv6 KAME 2 http://www.kame.net/ хитрит: она сначала сравнивает значение поля с единицей и только затем уменьшает его (или уничтожает пакет, если значение уже единица или меньше, то есть ноль). Алгоритм, приведенный в стандарте [§4.4 RFC 2460], тоже применяет этот трюк. Тем не менее, основной текст стандарта [§3 RFC 2460] обходит молчанием случай, когда поле "предельное число шагов" заранее содержит ноль. Это, конечно же, недоработка.

    Поле длины пакета необходимо на тот случай, если канальный уровень не сохраняет точную длину полезной нагрузки кадра. Хрестоматийный пример — это Ethernet , где длина полезной нагрузки не может быть ниже 46 байт из-за наследия CSMA/CD . Другой возможный пример — это канальный протокол, длина полезной нагрузки в котором должна быть кратна, скажем, восьми байтам.

    Подобное ограничение можно встретить в защищенных протоколах с блочным шифрованием, но оно не всегда заметно их потребителям. Например, подсистема шифрования PPP маскирует ее, сохраняя и восстанавливая точную длину полезной нагрузки с помощью особой набивки, в которой закодирована информация о числе добавленных в конец полезной нагрузки байтов [§6.1 RFC 2419]. Располагая такой информацией, приемник PPP может точно "срезать" набивку без вреда для полезной нагрузки.

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

    Хотя исторически байт не всегда был одной и той же длины, и потому возник альтернативный термин "октет", обозначавший именно цепочку из 8 бит, по состоянию на сегодняшний день это полные синонимы. Мы предпочитаем термин "байт", так как он понятен большей аудитории, а "октет" уже звучит старомодно, почти как французские реплики героев Льва Толстого.


    Тип Код Описание Обработчик или errno 1 Administratively prohibited, firewall filter (Запрещено администратором, фильтр брандмауэра) EHOSTUNREACH 2 Not a neighbor, incorrect strict source route (He сосед, некорректный маршрут отправителя) EHOSTUNREACH 3 Address unreachable (Адрес недоступен) EHOSTDOWN 4 Port unreachable (Порт недоступен) ECONNREFUSED 2 0 Packet too big (Слишком большой пакет) Ядро выполняет обнаружение транспортной MTU 3 Time exceeded (Превышено время передачи) 0 Hop limit exceeded in transit (При передаче превышено значение предельного количества транзитных узлов) Пользовательский процесс 1 Fragment reassembly time exceeded (Истекло время сборки из фрагментов) Пользовательский процесс 4 Parameter problem (Проблема с параметром) 0 Erroneous header filed (Ошибочное поле заголовка) ENOPROTOOPT 1 Unrecognized next header (Следующий заголовок нераспознаваем) ENOPROTOOPT 2 Unrecognized option (Неизвестный параметр) ENOPROTOOPT 128 0 Echo request (Эхо-запрос (Ping)) Ядро генерирует ответ 129 0 Echo reply (Эхо-ответ (Ping)) Пользовательский процесс (Ping) 130 0 Group membership query (Запрос о членстве в группе) Пользовательский процесс 131 0 Group membership report (Отчет о членстве в группе) Пользовательский процесс 132 0 Group membership reduction (Сокращение членства в группе) Пользовательский процесс 133 0 Router solicitation (Запрос маршрутизатору) Пользовательский процесс 134 0 Router advertisement (Извещение маршрутизатора) Пользовательский процесс 135 0 Neighbor solicitation (Запрос соседу) Пользовательский процесс 136 0 Neighbor advertisement (Извещение соседа) Пользовательский процесс 137 0 Redirect (Перенаправление) Ядро обновляет таблицу маршрутизации

    Данный текст является ознакомительным фрагментом.

    Продолжение на ЛитРес

    Приложение А Протоколы IPv4, IPv6, ICMPv4 и ICMFV6

    Приложение А Протоколы IPv4, IPv6, ICMPv4 и ICMFV6 А.1. Введение В этом приложении приведен обзор протоколов IPv4, IPv6, ICMPv4 и ICMPv6. Данный материал позволяет глубже понять рассмотренные в главе 2 протоколы TCP и UDP. Некоторые возможности IP и ICMP рассматриваются также более подробно и в других

    3.7. Подключение к сети Интернет

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

    Протоколы шифрования и аутентификации в сети

    Протоколы шифрования и аутентификации в сети Почему безопасность работы в сети играет огромную роль? Ответ на этот вопрос достаточно простой: предприятие, на котором функционирует сеть, может в своей работе использовать разные документы и данные, предназначенные только

    2.3. Интернет по локальной сети

    2.3. Интернет по локальной сети 2.3.1. Настройка локальной сети Интернет по локальной сети чаще всего встречается на предприятиях или в небольших домашних сетях. Как правило, в сети есть главный компьютер - шлюз, предоставляющий всем остальным компьютерам сети доступ к

    Интернет и сети

    Интернет и сети В этом разделе находятся несколько параметров, с помощью которых можно настраивать некоторые параметры браузера Internet Explorer, а также влиять на поведение компьютера при работе в локальной сети (рис. 24.19). Рис. 24.19. Содержимое подраздела Локальные сети раздела

    Анонимность в сети интернет

    Передача файлов по сети Интернет (FTP)

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

    Часть IV Работа в сети Интернет

    Часть IV Работа в сети Интернет Глава 24 Подключение к локальной сети • Проводная локальная сеть• Настройка сетевого соединения1 сентября 1969 года считается датой рождения Интернета. Впервые с помощью специального кабеля были объединены два компьютера, которые могли

    Глава 25 Настройка подключения к сети Интернет

    Глава 25 Настройка подключения к сети Интернет • Настройка подключения по проводной локальной сети• Подключение по беспроводной локальной

    3.11.4. Устранение неполадок при подключении к сети Интернет

    3.11.4. Устранение неполадок при подключении к сети Интернет Окно Сеть (Network) помимо настроек сетевых интерфейсов используется для определения активного соединения; так, например, на рис. 3.33 работающим соединением является AirPort, которое автоматически располагается на

    Читайте также: