Ipv6 prefix: Основы IPv6 / Хабр

Содержание

введение в IPv6 / Хабр

Этой статьёй я хочу начать цикл, посвященный IPv6. Я являюсь инструктором академии Cisco, поэтому, если вы в совершенстве знаете материал нового CCNA Routing & Switching, то скорее всего, не найдёте в цикле ничего нового. Речь пойдёт о структуре и особенностях протокола IPv6, а также, применении его на маршрутизаторах Cisco (маршрутизация RIP, OSPF, EIGRP, списки контроля доступа, и др. – как пойдёт). В первой статье мы поговорим о структуре IPv6 пакета, записи адресов, префиксе. Вторая статья цикла доступна здесь. Информация подойдёт для новичков, имеющих, тем не менее, некоторые знания по IPv4 и модели OSI.
Цикл статей основан на материалах моего блога, которые, в свою очередь, основаны на опыте преподавания, работы с оборудованием и вольном переводе и обдумывании официального курса CCNA Routing & Switching.
Итак, начнём. Не буду останавливаться на стандартных рассуждениях о том, что IPv4 адресов мало, о том, что NAT и прокси – это костыли, о том, что костыли пока работают, и никто не хочет переходить на IPv6, вместо этого – сразу к сути.


Адреса IPv6

Адрес протокола IPv6 состоит из 128 бит, то есть, он в 4 раза длиннее 32-битного IPv4 адреса. Подобно IPv4, в этом адресе можно выделить две части: сеть и хост. То есть, не все биты в адресе имеют одинаковое значение. Часть битов слева (сколько именно зависит от префикса) обозначают сеть, остальные биты справа – идентифицируют устройство внутри сети. Часть, ответственная за хранение информации о хосте называется идентификатор интерфейса (interface id). В отличие от предыдущей версии протокола, в IPv6 не применяются маски подсети, так как они получились бы очень длинными, вместо этого используется префикс. который записывается так же через слеш после адреса. Например, префикс /64 означает, что из 128 бит, первые 64 – это сеть, а оставшаяся часть (в данном случае вторые 64) – это хост. Префикс описывает, сколько бит в адресе используется под хранение информации о сети.
Сам адрес записывают не в десятичном, а в шестнадцатеричном виде – так короче. Адрес разбивается на группы по 16 бит (хекстеты) и каждая группа представляется четырьмя шестнадцатеричными цифрами. Хекстеты отделяются друг от друга знаком двоеточия. Таким образом, адрес состоит из 8 хекстетов ([8 хекстетов]*[16 бит в хекстете]=[128 бит] – общая длина адреса).
Сокращение IPv6

Пример адреса: 2001:0DB8:AA10:0001:0000:0000:0000:00FB. С таким длинным адресом работать достаточно неудобно, поэтому применяют сокращённую запись.
Для того чтобы сократить данный адрес надо последовательно применить два правила.
Правило 1

В каждом хекстете (группе из 4-х цифр) ведущие нули удаляются. Например, во втором хекстете 0DB0 заменяется на DB0. То есть ноль слева удаляется, ноль справа мы не трогаем. Если хекстет состоит из одних нулей, то он заменяется на один нуль. Таким образом адрес 2001:0DB0:0000:123A:0000:0000:0000:0030 преобразуется в 2001:DB0:0:123A:0:0:0:30. А, например, адрес loopback 0000:0000:0000:0000:0000:0000:0000:0001 заменяется на 0:0:0:0:0:0:0:1.
Правило 2

Это правило применяется только после первого. В адрес выбирается одна самая длинная группа, состоящая из полностью нулевых хекстетов, то есть самая длинная последовательность «:0:0:0:» и заменяется на два двоеточия «::». Эту замену можно произвести только один раз и только с самой длинной последовательностью, так как, если бы мы, например, сделали такую замену в двух местах адреса, то потом нельзя было бы восстановить, сколько именно хекстетов мы заменили в первом и во втором случае. Важный момент: нельзя заменять одну группу из :0: на ::, правило два применимо только если есть более одной нулевой группы.
Для примера возьмём адрес из предыдущей замены 2001:DB0:0:123A:0:0:0:30. Самая длинная последовательность из полностью пустых хекстетов – это «:0:0:0:», она начинается сразу после хекстета «123A». Есть ещё последовательность из одного пустого хекстета (между «DB0» и «123A»), но эта – длиннее, так что заменять будем её. Адрес станет совсем небольшим: 2001:DB0:0:123A::30 конечно, длиннее IPv4 адреса, но гораздо короче исходного.
Получение исходного адреса по сокращённой записи

Эта процедура достаточно тривиальна, если мы уже умеем сокращать адреса.
Сначала надо посчитать, сколько хекстетов в адресе осталось. В нашем случае, в адресе 2001:DB0:0:123A::30 осталось 5 хекстетов. Мы знаем, что адрес должен состоять из восьми хекстетов – значит вместо «::» возвращаем три недостающих нулевых, получаем 2001:DB0:0:123A:0:0:0:30. Теперь в каждой группе, где меньше четырёх цифр дописываем слева такое количество нулей, чтобы в группе стало четыре цифры. В результате получим исходный адрес 2001:0DB0:0000:123A:0000:0000:0000:0030.
Примеры

Теперь, чтобы закрепить понимание, приведём несколько примеров сокращения адресов. Сокращать будем по правилам в два этапа.
  • FF80:0000:0000:0000:0123:1234:ABCD:EF12 → FF80:0:0:0:123:1234:ABCD:EF12 → FF80::123:1234:ABCD:EF12
  • FF02:0000:0000:0000:0000:0001:FF00:0300 → FF02:0:0:0:0:1:FF00:300 → FF02::1:FF00:300
  • 2001:0DB8:0000:1111:0000:0000:0000:0200 → 2001:DB8:0:1111:0:0:0:200 → 2001:DB8:0:1111::200
  • 0000:0000:0000:0000:0000:0000:0000:0001 → 0:0:0:0:0:0:0:1 → ::1
  • 0000:0000:0000:0000:0000:0000:0000:0000 → 0:0:0:0:0:0:0:0 → ::

Адрес loopback выглядит в сокращённой записи особенно элегантно ::1. Даже если вы не пользуетесь IPv6, но работаете на одной из современных операционных, систем, у вас наверняка установлен этот протокол. Это легко проверить, пропинговав loopback.
ping ::1 Pinging ::1 with 32 bytes of data: Reply from ::1: time<1ms Reply from ::1: time<1ms Reply from ::1: time<1ms Reply from ::1: time<1ms Ping statistics for ::1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

При использовании IPv6 адреса в качестве URL, его необходимо заключать в квадратные скобки, при этом, если необходимо указать в URL-е порт, то его следует писать за пределами скобок – http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/.
Виды IPv6 адресов

Выделяется несколько типов адресов:
  • Глобальный юникаст (Global unicast) – это аналог публичных адресов в IPv4. Большая часть всех адресов относятся именно к этому классу.
    Эти адреса должны быть уникальными в пределах всего интернета, они выдаются IANA региональным регистраторам, те выдают их провайдерам, а провайдеры – выдают клиентам. Диапазон этих адресов – это все адреса, у которых первые три бита равны «001», что означает все адреса, у которых первый хекстет лежит в диапазоне от 2000 до 3FFF. Из этой группы отдельно выделяется сеть 2001:0DB8::/32, которая, согласно спецификации, используется для примеров и документации.
  • Локальные адреса (Link-local) – адреса, использующиеся для взаимодействия с другими устройствами в той же локальной сети. Отличительной особенностью этих адресов является то, что трафик «с» или «на» эти адреса не маршрутизируется и в принципе не может выйти за пределы той сети, в которой он был создан. Уникальность от этих адресов не требуется – в каждой сети они могут быть одними и теми же. Адреса применяются для разных специальных целей, например, для процедуры обнаружения соседей (аналог ARP в IPv6). Диапазон таких адресов FE80::/10 – что означает все адреса у которых первый хекстет в диапазоне от FE80 до FEBF.
  • Мультикастовые адресе (Multicast) – адреса, использующийся для мультикастовой рассылки. Все эти адреса находятся в диапазоне FF00::/8, что по-русски означает «Всё что начинается с FF». Надо сказать, что мультикаст в IPv6 выполняет важную роль, так как в нём нет широковещательных пакетов и все рассылки делаются мультикастом. Это очень большая тема, поэтому о мультикастах в IPv6 мы поговорим в одной из следующих статей.
  • Loopback – специальный адрес ::1. Все пакеты, идущие на него не выходят за пределы устройства, а попадают обратно на уровень IP. Таким образом, этот адрес аналогичен 127.0.0.1 в IPv4. Командой ping ::1 можно проверить, установлен ли на компьютере стек протоколов TCP/IP и IPv6 в частности.
  • Неопределённый адрес (Unspecified address) – адрес, состоящий из одних нулей. Записывается в сокращённой форме как «::». Такой адрес не может быть назначен интерфейсу, но может использоваться в некоторых пакетах в качестве адреса отправителя. Например, когда устройство ещё не получило IP адрес с помощью автоматической конфигурации, о ней – тоже в одной из следующих статей.
  • Уникальные локальные адреса (Unique local) – аналог приватных адресов в IPv4, то есть они могут маршрутизироваться в пределах нашей внутренней сети, но в интернет их анонсировать нельзя. Вообще, IPv6 подразумевает отказ от приватных адресов в том смысле, в котором они использовались до этого. В IPv4 приватные адреса применяются в основном из-за нехватки публичных и только иногда из соображений безопасности. В IPv6 использовать локальные адреса надо только в том случае, если по соображениям безопасности трафик из данной сети и в неё не должен уходить за пределы нашей зоны ответственности. Во всех остальных случаях следует использовать глобальные юникастовые адреса.
  • Адреса IPv4, отображенные в IPv6 (IPv4 embedded) – это адреса вида ::ffff:xxxx:xxxx, где xxxx:xxxx – это некоторый IPv4 адрес, переведённый в шестнадцатеричный вид. Эти адреса используются для устройств, не поддерживающих IPv6 и обеспечивают способ отображения адресного пространства старой версии протокола в адресное пространство новой.

Выше было сказано, что клиенту, как правило, выдаётся огромная сеть (64 бита префикс), а первые 64 бита – это идентификатор сети. Понятно, однако, что сама эта сеть тоже имеет иерархическую структуру. Как правило, региональный регистратор отдаёт провайдеру сеть с префиксом /48, а провайдер добавляет от себя ещё 16 бит и получает 65536 сетей с префиксом /64, которые затем отдаёт своим клиентам.
UPD1: В комментариях подсказывают «Региональные регистраторы давно уже дают /32 сеть по умолчанию или больше адресов, если сможешь обосновать зачем.»
UPD2: Важное замечание в комментариях относительно IPv4 embedded адресов: «Mapped-адреса используются, прежде всего, в dual-stack. Когда создаётся один сокет IPv6 на оба протокола ( IPv4 и IPv6 ), и везде используется IPv6 адреса. Т. е. если через этот сокет пришли данные через IPv4, адрес будет показан всё равно в виде вышеописанного IPv6 mapped-адреса. На канальном уровне разницы не будет вообще. Там будет старый добрый IPv4, разница только в в унификации отображения для пользователя.»
UPD3: Готова вторая статья цикла.
UPD4: Внимательный пользователь сообщил мне на счёт сокращения адресов интересную информацию, о которой я не знал. Правило 2, по RFC5952, применимо только когда у нас более одной группы, состоящей из нулей. То есть …:0:… нельзя заменить на …::…, а …:0:0:… — уже можно.

введение в IPv6 / Habr

Этой статьёй я хочу начать цикл, посвященный IPv6. Я являюсь инструктором академии Cisco, поэтому, если вы в совершенстве знаете материал нового CCNA Routing & Switching, то скорее всего, не найдёте в цикле ничего нового. Речь пойдёт о структуре и особенностях протокола IPv6, а также, применении его на маршрутизаторах Cisco (маршрутизация RIP, OSPF, EIGRP, списки контроля доступа, и др. – как пойдёт). В первой статье мы поговорим о структуре IPv6 пакета, записи адресов, префиксе. Вторая статья цикла доступна здесь. Информация подойдёт для новичков, имеющих, тем не менее, некоторые знания по IPv4 и модели OSI.
Цикл статей основан на материалах моего блога, которые, в свою очередь, основаны на опыте преподавания, работы с оборудованием и вольном переводе и обдумывании официального курса CCNA Routing & Switching.
Итак, начнём. Не буду останавливаться на стандартных рассуждениях о том, что IPv4 адресов мало, о том, что NAT и прокси – это костыли, о том, что костыли пока работают, и никто не хочет переходить на IPv6, вместо этого – сразу к сути.

Адреса IPv6

Адрес протокола IPv6 состоит из 128 бит, то есть, он в 4 раза длиннее 32-битного IPv4 адреса. Подобно IPv4, в этом адресе можно выделить две части: сеть и хост. То есть, не все биты в адресе имеют одинаковое значение. Часть битов слева (сколько именно зависит от префикса) обозначают сеть, остальные биты справа – идентифицируют устройство внутри сети. Часть, ответственная за хранение информации о хосте называется идентификатор интерфейса (interface id). В отличие от предыдущей версии протокола, в IPv6 не применяются маски подсети, так как они получились бы очень длинными, вместо этого используется префикс. который записывается так же через слеш после адреса. Например, префикс /64 означает, что из 128 бит, первые 64 – это сеть, а оставшаяся часть (в данном случае вторые 64) – это хост. Префикс описывает, сколько бит в адресе используется под хранение информации о сети.
Сам адрес записывают не в десятичном, а в шестнадцатеричном виде – так короче. Адрес разбивается на группы по 16 бит (хекстеты) и каждая группа представляется четырьмя шестнадцатеричными цифрами. Хекстеты отделяются друг от друга знаком двоеточия. Таким образом, адрес состоит из 8 хекстетов ([8 хекстетов]*[16 бит в хекстете]=[128 бит] – общая длина адреса).
Сокращение IPv6

Пример адреса: 2001:0DB8:AA10:0001:0000:0000:0000:00FB. С таким длинным адресом работать достаточно неудобно, поэтому применяют сокращённую запись.
Для того чтобы сократить данный адрес надо последовательно применить два правила.
Правило 1

В каждом хекстете (группе из 4-х цифр) ведущие нули удаляются. Например, во втором хекстете 0DB0 заменяется на DB0. То есть ноль слева удаляется, ноль справа мы не трогаем. Если хекстет состоит из одних нулей, то он заменяется на один нуль. Таким образом адрес 2001:0DB0:0000:123A:0000:0000:0000:0030 преобразуется в 2001:DB0:0:123A:0:0:0:30. А, например, адрес loopback 0000:0000:0000:0000:0000:0000:0000:0001 заменяется на 0:0:0:0:0:0:0:1.
Правило 2

Это правило применяется только после первого. В адрес выбирается одна самая длинная группа, состоящая из полностью нулевых хекстетов, то есть самая длинная последовательность «:0:0:0:» и заменяется на два двоеточия «::». Эту замену можно произвести только один раз и только с самой длинной последовательностью, так как, если бы мы, например, сделали такую замену в двух местах адреса, то потом нельзя было бы восстановить, сколько именно хекстетов мы заменили в первом и во втором случае. Важный момент: нельзя заменять одну группу из :0: на ::, правило два применимо только если есть более одной нулевой группы.
Для примера возьмём адрес из предыдущей замены 2001:DB0:0:123A:0:0:0:30. Самая длинная последовательность из полностью пустых хекстетов – это «:0:0:0:», она начинается сразу после хекстета «123A». Есть ещё последовательность из одного пустого хекстета (между «DB0» и «123A»), но эта – длиннее, так что заменять будем её. Адрес станет совсем небольшим: 2001:DB0:0:123A::30 конечно, длиннее IPv4 адреса, но гораздо короче исходного.
Получение исходного адреса по сокращённой записи

Эта процедура достаточно тривиальна, если мы уже умеем сокращать адреса.
Сначала надо посчитать, сколько хекстетов в адресе осталось. В нашем случае, в адресе 2001:DB0:0:123A::30 осталось 5 хекстетов. Мы знаем, что адрес должен состоять из восьми хекстетов – значит вместо «::» возвращаем три недостающих нулевых, получаем 2001:DB0:0:123A:0:0:0:30. Теперь в каждой группе, где меньше четырёх цифр дописываем слева такое количество нулей, чтобы в группе стало четыре цифры. В результате получим исходный адрес 2001:0DB0:0000:123A:0000:0000:0000:0030.
Примеры

Теперь, чтобы закрепить понимание, приведём несколько примеров сокращения адресов. Сокращать будем по правилам в два этапа.
  • FF80:0000:0000:0000:0123:1234:ABCD:EF12 → FF80:0:0:0:123:1234:ABCD:EF12 → FF80::123:1234:ABCD:EF12
  • FF02:0000:0000:0000:0000:0001:FF00:0300 → FF02:0:0:0:0:1:FF00:300 → FF02::1:FF00:300
  • 2001:0DB8:0000:1111:0000:0000:0000:0200 → 2001:DB8:0:1111:0:0:0:200 → 2001:DB8:0:1111::200
  • 0000:0000:0000:0000:0000:0000:0000:0001 → 0:0:0:0:0:0:0:1 → ::1
  • 0000:0000:0000:0000:0000:0000:0000:0000 → 0:0:0:0:0:0:0:0 → ::

Адрес loopback выглядит в сокращённой записи особенно элегантно ::1. Даже если вы не пользуетесь IPv6, но работаете на одной из современных операционных, систем, у вас наверняка установлен этот протокол. Это легко проверить, пропинговав loopback.
ping ::1
Pinging ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Ping statistics for ::1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

При использовании IPv6 адреса в качестве URL, его необходимо заключать в квадратные скобки, при этом, если необходимо указать в URL-е порт, то его следует писать за пределами скобок – http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/.
Виды IPv6 адресов

Выделяется несколько типов адресов:
  • Глобальный юникаст (Global unicast) – это аналог публичных адресов в IPv4. Большая часть всех адресов относятся именно к этому классу. Эти адреса должны быть уникальными в пределах всего интернета, они выдаются IANA региональным регистраторам, те выдают их провайдерам, а провайдеры – выдают клиентам. Диапазон этих адресов – это все адреса, у которых первые три бита равны «001», что означает все адреса, у которых первый хекстет лежит в диапазоне от 2000 до 3FFF. Из этой группы отдельно выделяется сеть 2001:0DB8::/32, которая, согласно спецификации, используется для примеров и документации.
  • Локальные адреса (Link-local) – адреса, использующиеся для взаимодействия с другими устройствами в той же локальной сети. Отличительной особенностью этих адресов является то, что трафик «с» или «на» эти адреса не маршрутизируется и в принципе не может выйти за пределы той сети, в которой он был создан. Уникальность от этих адресов не требуется – в каждой сети они могут быть одними и теми же. Адреса применяются для разных специальных целей, например, для процедуры обнаружения соседей (аналог ARP в IPv6). Диапазон таких адресов FE80::/10 – что означает все адреса у которых первый хекстет в диапазоне от FE80 до FEBF.
  • Мультикастовые адресе (Multicast) – адреса, использующийся для мультикастовой рассылки. Все эти адреса находятся в диапазоне FF00::/8, что по-русски означает «Всё что начинается с FF». Надо сказать, что мультикаст в IPv6 выполняет важную роль, так как в нём нет широковещательных пакетов и все рассылки делаются мультикастом. Это очень большая тема, поэтому о мультикастах в IPv6 мы поговорим в одной из следующих статей.
  • Loopback – специальный адрес ::1. Все пакеты, идущие на него не выходят за пределы устройства, а попадают обратно на уровень IP. Таким образом, этот адрес аналогичен 127.0.0.1 в IPv4. Командой ping ::1 можно проверить, установлен ли на компьютере стек протоколов TCP/IP и IPv6 в частности.
  • Неопределённый адрес (Unspecified address) – адрес, состоящий из одних нулей. Записывается в сокращённой форме как «::». Такой адрес не может быть назначен интерфейсу, но может использоваться в некоторых пакетах в качестве адреса отправителя. Например, когда устройство ещё не получило IP адрес с помощью автоматической конфигурации, о ней – тоже в одной из следующих статей.
  • Уникальные локальные адреса (Unique local) – аналог приватных адресов в IPv4, то есть они могут маршрутизироваться в пределах нашей внутренней сети, но в интернет их анонсировать нельзя. Вообще, IPv6 подразумевает отказ от приватных адресов в том смысле, в котором они использовались до этого. В IPv4 приватные адреса применяются в основном из-за нехватки публичных и только иногда из соображений безопасности. В IPv6 использовать локальные адреса надо только в том случае, если по соображениям безопасности трафик из данной сети и в неё не должен уходить за пределы нашей зоны ответственности. Во всех остальных случаях следует использовать глобальные юникастовые адреса.
  • Адреса IPv4, отображенные в IPv6 (IPv4 embedded) – это адреса вида ::ffff:xxxx:xxxx, где xxxx:xxxx – это некоторый IPv4 адрес, переведённый в шестнадцатеричный вид. Эти адреса используются для устройств, не поддерживающих IPv6 и обеспечивают способ отображения адресного пространства старой версии протокола в адресное пространство новой.

Выше было сказано, что клиенту, как правило, выдаётся огромная сеть (64 бита префикс), а первые 64 бита – это идентификатор сети. Понятно, однако, что сама эта сеть тоже имеет иерархическую структуру. Как правило, региональный регистратор отдаёт провайдеру сеть с префиксом /48, а провайдер добавляет от себя ещё 16 бит и получает 65536 сетей с префиксом /64, которые затем отдаёт своим клиентам.
UPD1: В комментариях подсказывают «Региональные регистраторы давно уже дают /32 сеть по умолчанию или больше адресов, если сможешь обосновать зачем. »
UPD2: Важное замечание в комментариях относительно IPv4 embedded адресов: «Mapped-адреса используются, прежде всего, в dual-stack. Когда создаётся один сокет IPv6 на оба протокола ( IPv4 и IPv6 ), и везде используется IPv6 адреса. Т. е. если через этот сокет пришли данные через IPv4, адрес будет показан всё равно в виде вышеописанного IPv6 mapped-адреса. На канальном уровне разницы не будет вообще. Там будет старый добрый IPv4, разница только в в унификации отображения для пользователя.»
UPD3: Готова вторая статья цикла.
UPD4: Внимательный пользователь сообщил мне на счёт сокращения адресов интересную информацию, о которой я не знал. Правило 2, по RFC5952, применимо только когда у нас более одной группы, состоящей из нулей. То есть …:0:… нельзя заменить на …::…, а …:0:0:… — уже можно.

IPv6

Введение

Адресация в IPv6

Базовая настройка интерфейсов

Статические маршруты

Динамическая маршрутизация

Списки доступа

Туннелирование в среде IPv4 и IPv6

Виртуальные процессы маршрутизации (VRF)

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

Заключение

Введение

Протокол IPv6 является наследником повсеместно используемого сегодня протокола IP четвёртой версии, IPv4, и естественно, наследует большую часть логики работы этого протокола. Так, например, заголовки пакетов в IPv4 и IPv6 очень похожи, используется та же логика пересылки пакетов – маршрутизация на основе адреса получателя, контроль времени нахождения пакета в сети с помощью TTL и так далее. Однако, есть и существенные отличия: кроме изменения длины самого IP-адреса, произошёл отказ от использования широковещания в любой форме, включая направленное (Broadcast, Directed broadcast). Вместо него теперь используются групповые рассылки (multicast). Также исчез ARP-протокол, функции которого возложены на ICMP, что заставит отделы информационной безопасности внимательнее относиться к данному протоколу, так как простое его запрещение уже стало невозможным. Мы не станем описывать все изменения, произошедшие с протоколом, так как читатель сможет с лёгкостью найти их на большинстве IT-ресурсов. Вместо этого покажем практические примеры настройки устройств на базе Cisco IOS для работы с IPv6.

Многие начинающие сетевые специалисты задаются вопросом: «Нужно ли сейчас начинать изучать IPv6?» На наш взгляд, сегодня уже нельзя подходить к IPv6 как к отдельной главе или технологии, вместо этого все изучаемые техники и методики следует отрабатывать сразу на обеих версиях протокола IP. Так, например, при изучении работы протокола динамической маршрутизации EIGRP стоит проводить настройку тестовых сетей в лаборатории как для IPv4, так и для IPv6 одновременно. Перейдём от слов к делу!

Адресация в IPv6

Длина адреса протокола IPv6 составляет 128 бит, что в четыре раза больше той, которая была в IPv4. Количество адресов IPv6 огромно и составляет 2128≈3,4•1038. Сам адрес протокола IPv6 можно разделить на две части: префикс и адрес хоста, который ещё называют идентификатором интерфейса. Такое деление очень похоже на то, что использовалось в IPv4 при бесклассовой маршрутизации.

Адреса в IPv6 записываются в шестнадцатеричной форме, каждая группа из четырёх цифр отделяется двоеточием. Например, 2001:1111:2222:3333:4444:5555:6666:7777. Маска указывается через слеш, то есть, например, /64. В адресе протокола IPv6 могут встречаться длинные последовательности нулей, поэтому предусмотрена сокращённая запись адреса. Во-первых, могут не записываться начальные нули каждой группы цифр, то есть вместо адреса 2001:0001:0002:0003:0004:0005:0006:7000 можно записать 2001:1:2:3:4:5:6:7000. Конечные нули при этом не удаляются. В случае, когда группа цифр в адресе (или несколько групп подряд) содержит только нули, она может быть заменена на двойное двоеточие. Например, вместо адреса 2001:1:0:0:0:0:0:1 может использоваться сокращённая запись вида 2001:1::1. Стоит отметить, что сократить адрес таким образом можно только один раз. Ниже приводятся правильные и неправильные формы записи IPv6 адресов.

Правильная запись.

2001:0000:0db8:0000:0000:0000:07a0:765d
2001:0:db8:0:0:0:7a0:765d
2001:0:db8::7a0:765d

Ошибочная форма.

2001::db8::7a0:765d
2001:0:db8::7a:765d

Забавные сокращения.

::/0 – шлюз по умолчанию
::1 – loopback
2001:2345:6789::/64 – адрес какой-то сети

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

  • Unicast
  • Multicast
  • Anycast

Адреса Unicast очень похожи на аналогичные адреса протокола IPv4, они могут назначаться интерфейсам сетевых устройств, серверам и хостам конечных пользователей. Групповые или Multicast адреса предназначены для доставки пакетов сразу нескольким получателям, входящим в группу. При использовании Anycast адресов данные будут получены ближайшим узлом, которому назначен такой адрес. Стоит обратить особое внимание на то, что в списке поддерживаемых протоколом IPv6 адресов отсутствуют широковещательные адреса. Даже среди Unicast адресов существует более мелкое дробление на типы.

  • Link local
  • Global unicast
  • Unique local

Адреса, относящиеся к группе Unique local, описаны в RFC 4193 и по своему назначению очень похожи на приватные адреса протокола IPv4, описанные в RFC 1918. Адреса группы Link local предназначены для передачи информации между устройствами, подключёнными к одной L2-сети. Большинство адресов из диапазона Global unicast могут быть назначены интерфейсам конкретных сетевых узлов. Список зарезервированных адресов представлен ниже.

IPv6 адрес Длина префикса Описание Заметки
:: 128 Аналог 0.0.0.0 в IPv4
::1 128 Loopback Аналог 127.0.0.1 в IPv4
::xx.xx.xx.xx 96 Встроенный IPv4 IPv4 совместимый. Устарел, не используется
::ffff:xx. xx.xx.xx 96 IPv4, отображённый на IPv6 Для хостов, не поддерживающих IPv6
2001:db8:: 32 Документирование Зарезервирован для примеров. RFC 3849
fe80:: — febf:: 10 Link-Local Аналог 169.254.0.0/16 в IPv4
fec0:: — feff:: 10 Site-Local Аналог сетей 10.0.0.0, 172.16.0.0, 192.168.0.0. RFC 3879. Устарел.
fc00:: 7 Unique Local Unicast Пришёл на смену Site-Local. RFC 4193
ffxx:: 8 Multicast

Базовая настройка интерфейсов

Включение маршрутизации IPv6 производится с помощью команды ipv6 unicast-routing. Z
R1#show ipv6 int bri
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C800:3FFF:FED0:A008

Вычисление части адреса link-local производится с помощью алгоритма EUI-64 на основе MAC-адреса интерфейса. Для этого в середину 48 байтного МАС-адреса автоматически дописывается два байта, которые в шестнадцатеричной записи имеют вид FFFE, а также производится инвертирование седьмого бита первого байта MAC-адреса. На рисунках ниже схематично показана работа обсуждаемого алгоритма.

Сравните указанный выше link-local адрес с физическим адресом интерфейса Gi0/0 маршрутизатора (несущественная часть вывода команды sho int Gi0/0 удалена).

R1#show int gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca00.3fd0.a008 (bia ca00.3fd0.a008)

EUI-64 часть IPv6 адреса: C800:3FFF:FED0:A008.

Назначение адреса на интерфейс вручную производится с помощью команды ipv6 address, например, ipv6 address 2001:db8::1/64. Z
R2#show ipv6 int bri
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C801:42FF:FEA4:8
2001:DB8::C801:42FF:FEA4:8

Обмен сообщениями внутри одного L2-сегмента только с помощью адресов link-local возможен и в некоторых случаях используется, однако в большинстве ситуаций интерфейсу должен быть назначен обычный маршрутизируемый IPv6-адрес. Так, например, соседство по протоколам OSPF или EIGRP устанавливается с использованием link-local адресов. Автоматический поиск соседа и другие служебные протоколы также работают по link-local адресам.

R1#sho ipv6 int brief
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C800:42FF:FEA4:8
2001:DB8::1
R1#sho ipv ei ne
IPv6-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 12 00:01:03 39 234 0 3
FE80::C801:42FF:FEA4:8
R1#ping FE80::C801:42FF:FEA4:8
Output Interface: GigabitEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::C801:42FF:FEA4:8, timeout is 2 seconds:
Packet sent with a source address of FE80::C800:42FF:FEA4:8
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/48 ms

Естественно, сохранилась и возможность автоматического назначения адреса в IPv6 с помощью протокола DHCP. Стоит, правда, отметить, что в IPv6 существует два различных типа DHCP: stateless и stateful, настройка которых производится с помощью команд ipv6 address autoconfig и ipv6 address dhcp соответственно.

Настройка «серверной» части практически не отличается от таковой для IPv4. Сначала требуется создать DHCP пул, после чего привязать его к интерфейсу. Привязка к интерфейсу осуществляется в явном виде с помощью интерфейсной команды ipv6 dhcp server name, где в качестве name выступает имя ранее созданного пула DHCP. Здесь же стоит отметить, что DHCPv6 не позволяет исключать определённые IPv6 адреса из диапазона так, как это делалось для IPv4 с помощью команды ip dhcp excluded-address, равно как и осуществлять ручную привязку адреса к клиенту.

ipv6 dhcp pool test
address prefix 2001:1::/64
dns-server 2001:1::1
domain-name foxnetwork.ru
interface GigabitEthernet1/0
no ip address
negotiation auto
ipv6 address 2001:1::1/64
ipv6 dhcp server test
ipv6 nd managed-config-flag
ipv6 nd other-config-flag

Команда ipv6 nd managed-config-flag указывает клиенту на необходимость использования DHCPv6 для получения адреса. Также можно уведомить клиента о необходимости получения дополнительных параметров (адрес DNS-сервера или имя домена) с помощью команды ipv6 nd other-config-flag.

Просмотреть информацию о настроенных пулах DHCPv6 можно с помощью команды show ipv6 dhcp pool.

R2#sho ipv dhcp pool
DHCPv6 pool: test
Address allocation prefix: 2001:1::/64 valid 172800 preferred 86400 (1 in use, 0 conflicts)
DNS server: 2001:1::1
Domain name: foxnetwork.ru
Active clients: 1

Список текущих клиентов отображается в выводе команды show ipv6 dhcp binding.

R2#show ipv6 dhcp binding
Client: FE80::C801:26FF:FEFC:1C
DUID: 00030001CA0126FC0008
Username : unassigned
IA NA: IA ID 0x00050001, T1 43200, T2 69120
Address: 2001:1::CDFD:B868:5AFF:F258
preferred lifetime 86400, valid lifetime 172800
expires at Mar 12 2015 08:56 AM (170469 seconds)

Сброс текущих привязок DHCPv6 производится с помощью команды clear ipv6 dhcp binding {* | ipv6-address}.

Вывод списка интерфейсов, на которых задействован протокол DHCPv6 производится с помощью команды show ipv6 dhcp interface.

R2#show ipv6 dhcp interface
GigabitEthernet1/0 is in server mode
Using pool: test
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabled

Кроме stateful DHCPv6 оборудование Cisco поддерживает также версию DHCPv6 Lite, отличающуюся отсутствием команды address prefix внутри пула и интерфейсной опции managed-config-flag. В этом случае адрес интерфейса узла вычисляется на основе сообщения Router Advertisement.

ipv6 dhcp pool test
dns-server 2001:1::1
domain-name foxnetwork.ru
interface GigabitEthernet1/0
no ip address
negotiation auto
ipv6 address 2001:1::1/64
ipv6 dhcp server test
ipv6 nd other-config-flag

Также как и для IPv4 L3-коммутаторы и маршрутизаторы Cisco могут выполнять функции DHCP ретранслятора, для чего используется команда ipv6 dhcp relay destination ipv6-address, где ipv6-address – адрес сервера DHCPv6.

В DHCPv6 появилась очень интересная возможность – делегирование префиксов. Данная функция, на наш взгляд, будет наиболее востребована операторами связи, так как позволяет делегировать клиенту большой префикс для распределения внутри его корпоративной сети. Рассмотрим работу функции Prefix Delegation на примере. На схеме ниже маршрутизатор Delegating_router представляет оконечное оборудование оператора, CE_router – граничное оборудование клиента. Маршрутизаторы Client_net1 и Client_net2 эмулируют устройства, подключённые в разные IPv6-сети клиента. Z
CE_router#

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

Delegating_router(config)#ipv6 local pool c_prefix 2001:DB8::/40 48

Пул c_prefix определён префиксом 2001:DB8::/40, из которого клиентам будут раздаваться меньшие префиксы с маской /48.

Вслед за локальным пулом необходимо создать пул DHCPv6, который привязать к интерфейсу Gi1/0.

Delegating_router(config)#ipv6 dhcp pool customers
Delegating_router(config-dhcpv6)# prefix-delegation pool c_prefix
Delegating_router(config-dhcpv6)#int gi1/0
Delegating_router(config-if)#ipv6 dhcp server customers

Настройка делегирующего маршрутизатора на этом завершается. На граничном маршрутизаторе клиента делегируемый префикс необходимо принять с помощью интерфейсной команды ipv6 dhcp client pd prefix, где prefix – имя принимаемого префикса, это имя будет использоваться в дальнейшем.

CE_router#sho run int gi0/0
Building configuration. ..
Current configuration : 170 bytes
interface GigabitEthernet0/0
no ip address
ipv6 address 2001:DB8:1::2/64
ipv6 dhcp client pd prefix
end
CE_router#sho ipv dhcp interface gi0/0
GigabitEthernet0/0 is in client mode
Prefix State is OPEN
Renew will be sent in 3d10h
Address State is IDLE
List of known servers:
Reachable via address: FE80::C801:2FF:FEC8:1C
DUID: 00030001CA0102C80008
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00040001, T1 302400, T2 483840
Prefix: 2001:DB8::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Apr 09 2015 10:39 AM (2587501 seconds)
Information refresh time: 0
Prefix name: prefix
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled

Адреса клиентских подсетей будут назначаться из полученного префикса. Так как данному клиенту был выделен префикс 2001:DB8::/48, то адреса конечных сетей будут, например, такими 2001:DB8:0:1::/64 и 2001:DB8:0:2::/64. Произведём соответствующую настройку подынтерфейсов маршрутизатора CE_router. Как видно из приведённого ниже листинга, адреса не указываются в явном виде, вместо этого используется полученный ранее от провайдера префикс.

CE_router#sho run int gi1/0.2
Building configuration...
Current configuration : 97 bytes
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ipv6 address prefix ::1:0:0:0:1/64
end
CE_router#sho run int gi1/0.3
Building configuration...
Current configuration : 97 bytes
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ipv6 address prefix ::2:0:0:0:1/64
end

Единственное, что осталось сделать – получить адреса на клиентских узлах.

Client_net1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Client_net1(config)#int gi1/0
Client_net1(config-if)#no sh
*Mar 10 11:38:07.959: %LINK-3-UPDOWN: Interface GigabitEthernet1/0, changed state to up
*Mar 10 11:38:08. 959: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to up
Client_net1(config-if)#ipv6 address autoconfig
Client_net1(config-if)#exi
Client_net1(config)#exi
Client_net1#sho ipv int bri
GigabitEthernet1/0 [up/up]
FE80::C803:1EFF:FE3C:1C
2001:DB8:0:1:C803:1EFF:FE3C:1C
Client_net1#

Ещё одной возможностью, связанной с использованием префиксов, является опция глобального определения префикса для маршрутизатора. Такая возможность позволяет упростить процедуру назначения адресов на интерфейсы маршрутизатора или L3-коммутатора. Допустим, что организации выделена сеть 2001:db8:1::/48. Это означает, что все адреса будут начинаться с «2001:db8:1». Начать нужно с определения префикса.

R1(config)#ipv6 general-prefix ?
WORD General prefix name
R1(config)#ipv6 general-prefix fox ?
6rd 6rd
6to4 6to4
X:X:X:X::X/<0-128> IPv6 prefix
R1(config)#ipv6 general-prefix fox 2001:DB8:1::/48
R1(config)#do sho ipv gene
IPv6 Prefix fox, acquired via Manual configuration
2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite

После того, как префикс сконфигурирован, можно переходить к его непосредственному назначению на интерфейс. Z
R1#sho ipv int bri
Ethernet0/0 [administratively down/down]
GigabitEthernet0/0 [up/up]
FE80::C801:3CFF:FED0:8
2001:DB8:1:1::1
R1#sho run int gi0/0
Building configuration…
Current configuration : 144 bytes
interface GigabitEthernet0/0
no ip address
duplex full
speed 1000
media-type gbic
negotiation auto
ipv6 address fox ::1:0:0:0:1/64
end

Стоит обратить особое внимание на синтаксис, который используется при назначении адреса на интерфейс. Левая часть адреса заполняется битами из основного префикса (количество бит соответствует длине основного префикса). Оставшаяся часть берётся из указанного в команде ipv6 address адреса. В принципе, левая часть указываемого на интерфейсе адреса может быть любой, в примере выше она заполнена нулями.

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

R1#conf t
Enter configuration commands, one per line. Z
R1#sho ipv int bri
Ethernet0/0 [administratively down/down]
FE80::C801:3CFF:FED0:6
2001:DB8:1:2:C801:3CFF:FED0:6
GigabitEthernet0/0 [up/up]
FE80::C801:3CFF:FED0:8
2001:DB8:1:1::1

С помощью команды sho ipv general-prefix можно просмотреть, на каких интерфейсах сконфигурированы адреса, использующие определённый основной префикс.

R1#sho ipv general-prefix
IPv6 Prefix fox, acquired via Manual configuration
2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite
GigabitEthernet0/0 (Address command)
Ethernet0/0 (Address command)

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

R1#sho run | i general
ipv6 general-prefix fox 2001:DB8:1::/48
ipv6 general-prefix fox 2001:DB8:2::/48
R1#sho ipv gene
IPv6 Prefix fox, acquired via Manual configuration
2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite
2001:DB8:2::/48 Valid lifetime infinite, preferred lifetime infinite
GigabitEthernet0/0 (Address command)
Ethernet0/0 (Address command)
R1#sho ipv int bri
Ethernet0/0 [administratively down/down]
FE80::C801:3CFF:FED0:6
2001:DB8:1:2:C801:3CFF:FED0:6
2001:DB8:2:2:C801:3CFF:FED0:6
GigabitEthernet0/0 [up/up]
FE80::C801:3CFF:FED0:8
2001:DB8:1:1::1
2001:DB8:2:1::1

Как уже было отмечено ранее, в IPv6 протокол ARP более не используется. Определение соседей производится с помощью протокола NDP (Neighbor Discovery Protocol) путём обмена сообщениями ICMP, отправляя их на групповой адрес FF02::1.

R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::C801:42FF:FEA4:8 25 ca01.42a4.0008 STALE Gi0/0

В операционных системах семейства Windows также присутствует возможность просмотра списка соседей (аналог команды arp –a), правда, теперь придётся использовать более длинный системный вызов.

C:\>netsh interface ipv6 show neighbors
Interface 1: Loopback Pseudo-Interface 1
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
ff02::c Permanent
ff02::16 Permanent
ff02::1:2 Permanent
ff02::1:3 Permanent
ff02::1:ff1e:f939 Permanent
Interface 24: Подключение по локальной сети 4
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:db8:0: 5::1 00-11-5c-1b-3d-49 Reachable (Router)
fe80::ffff:ffff:fffe Unreachable Unreachable
fe80::211:5cff:fe1b:3d49 00-11-5c-1b-3d-49 Stale (Router)
fe80::218:f3ff:fe73:33d7 Unreachable Unreachable
fe80::a541:1a9:3b2d:7734 Unreachable Unreachable
ff02::1 33-33-00-00-00-01 Permanent
ff02::2 33-33-00-00-00-02 Permanent
ff02::c 33-33-00-00-00-0c Permanent
ff02::16 33-33-00-00-00-16 Permanent
ff02::1:2 33-33-00-01-00-02 Permanent
ff02::1:3 33-33-00-01-00-03 Permanent
ff02::1:ff00:0 33-33-ff-00-00-00 Permanent
ff02::1:ff00:1 33-33-ff-00-00-01 Permanent

Похожим образом осуществляется поиск маршрутизаторов в локальном сегменте, правда, в этом случае отправка пакетов производится на адрес FF02::2. Заинтересованный узел отправляет сообщение RS (Router Solicitation), на которое получает ответ RA (Router Advertisement) от маршрутизатора. Указанный ответ содержит параметры работы IP-протокола в данной сети. Описанный процесс представлен на рисунке ниже.

Обнаружение маршрутизатора, подключённого к сегменту локальной сети, используется для получения узлом адреса IPv6 с помощью процедуры stateless address autoconfiguration (SLAAC), которую ошибочно ещё называют Stateless DHCP.

Статические маршруты

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

R1#sho ipv6 routing
IPv6 Routing Table - Default - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
HA - Home Agent, MR - Mobile Router, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

Привычным способом задаются статические маршруты в IPv6. Z
R1#sho ipv6 routing
IPv6 Routing Table — Default — 4 entries
Codes: C — Connected, L — Local, S — Static, U — Per-user Static route
HA — Home Agent, MR — Mobile Router, R — RIP, I1 — ISIS L1
I2 — ISIS L2, IA — ISIS interarea, IS — ISIS summary, D — EIGRP
EX — EIGRP external
S ::/0 [1/0]
via FE80::C801:42FF:FEA4:8, GigabitEthernet0/0
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

Динамическая маршрутизация

Настройка динамической маршрутизации в IPv6 немногим сложнее. Во-первых, для добавления интерфейса в процесс маршрутизации команда network более не используется. Вместо этого на интерфейсе должна быть дана команда ipv6 eigrp 1 для включения EIGRP 1, либо ipv6 ospf 1 area 0 для добавления интерфейса в магистральную зону процесса OSPF 1. Процесс маршрутизации EIGRP для IPv6 по умолчанию выключен, поэтому его потребуется включить, но самой «приятной» особенностью является необходимость следить за назначением параметра router-id. Z
R1#sho ipv6 eigrp interfaces
EIGRP-IPv6 Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0/0 0 0/0 0 0
R1#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(1)

Введём аналогичные команды на R2, после это EIGRP-соседство устанавливается между двумя маршрутизаторами.

R1#
*Mar 21 12:01:13.763: %DUAL-5-NBRCHANGE: EIGRP-IPv6 1: Neighbor FE80::C80E:21FF:FEE4:8 (GigabitEthernet0/0) is up: new adjacency
R1#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 11 00:00:15 40 240 0 2
FE80::C80E:21FF:FEE4:8

На каждом из маршрутизаторов создадим интерфейс Loopback1, который будет эмулировать подключённые сети. На R1 интерфейсу Loopback1 назначим IPv6 адрес 2001:db8:1::1/64, на R2 – 2001:db8:2::1/64. Передать информацию о новых сетях в протокол динамической маршрутизации можно двумя способами: включить новый интерфейс в соответствующий протокол, либо выполнить перераспределение маршрутов (redistribute). Единственное, о чём следует помнить во втором случае, — о необходимости указания метрик. Метрика может быть указана либо в явном виде для каждого перераспределения, либо при помощи команды default-metric. Данное действие полностью аналогично IPv4, поэтому подробно останавливаться не будем.

Вывод с маршрутизатора R1.

R1#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
C 2001:DB8:1::/64 [0/0]
via Loopback1, directly connected
L 2001:DB8:1::1/128 [0/0]
via Loopback1, receive
EX 2001:DB8:2::/64 [170/2560512]
via FE80::C80E:21FF:FEE4:8, GigabitEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
R1#sho run int loo 1
Building configuration. ..
Current configuration : 87 bytes
interface Loopback1
no ip address
ipv6 address 2001:DB8:1::1/64
ipv6 eigrp 1
end
R1#sho run | sec router
ipv6 router eigrp 1
eigrp router-id 1.1.1.1

Вывод с маршрутизатора R2.

R2#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::2/128 [0/0]
via GigabitEthernet0/0, receive
D 2001:DB8:1::/64 [90/130816]
via FE80::C80D:1EFF:FE28:8, GigabitEthernet0/0
C 2001:DB8:2::/64 [0/0]
via Loopback1, directly connected
L 2001:DB8:2::1/128 [0/0]
via Loopback1, receive
L FF00::/8 [0/0]
via Null0, receive
R2#sho run int lo 1
Building configuration...
Current configuration : 73 bytes
interface Loopback1
no ip address
ipv6 address 2001:DB8:2::1/64
end
R2#sho run | sec router
ipv6 router eigrp 1
eigrp router-id 2.2.2.2
redistribute connected
default-metric 1000 1 100 100 1500

Если в сети используется протокол BGP, то для управления им придётся воспользоваться несколько иным подходом: в BGP не создаются различные процессы для IPv4 и IPv6. Вместо этого внутри одного «родительского» процесса деление на версии протокола IP производится с помощью команды address-family. Ниже приводится вывод с маршрутизатора R1. Настройка R2 выполнена аналогично.

R1#show run | sec router bgp
router bgp 65001
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 65002
!
address-family ipv4
no neighbor 2001:DB8::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1::/64
neighbor 2001:DB8::2 activate
exit-address-family
R1#show bgp ipv6 summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8::2 4 65002 12 12 3 0 0 00:07:24 1
% NOTE: This command is deprecated. Please use 'show bgp ipv6 unicast'
R1#show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8::2 4 65002 12 12 3 0 0 00:07:34 1
R1#show bgp ipv6 unicast
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1::/64 :: 0 32768 i
*> 2001:DB8:2::/64 2001:DB8::2 0 0 65002 i

На момент написания статьи (конец марта 2014 года) в глобальной таблице маршрутизации (BGP full view или BGP full table) насчитывалось примерно 500000 префиксов для IPv4 и около 17000 записей для IPv6.

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

interface GigabitEthernet0/0
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 enable
ipv6 ospf 1 area 0
router ospfv3 1
router-id 1.1.1.1
address-family ipv6 unicast
redistribute connected
exit-address-family

Списки доступа

В списках доступа также есть небольшие изменения. Так, например, установка листа на интерфейс производится командой ipv6 traffic-filter, например, ipv6 traffic-filter TEST in.

R2#show run | section access
ipv6 access-list TEST
deny icmp any any echo-reply
deny icmp any any echo-request
permit ipv6 any any
R2#show ipv6 access-list
IPv6 access list test
deny icmp any any echo-reply sequence 10
deny icmp any any echo-request (5 matches) sequence 20
permit ipv6 any any (28 matches) sequence 30
interface GigabitEthernet0/0
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 address 2001:DB8::2/64
ipv6 eigrp 1
ipv6 traffic-filter TEST in

После установки листа TEST на интерфейс Gi0/0 в приведённой выше схеме маршрутизатор R2 перестаёт отвечать на эхо-запросы по протоколу ICMP.

R1#ping 2001:db8::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8::2, timeout is 2 seconds:
AAAAA
Success rate is 0 percent (0/5)

Туннелирование в среде IPv4 и IPv6

Не менее интересный вопрос связан с работой туннелей, поддерживающих IPv6. Самыми простыми туннелями в среде IPv4 были IPIP (IP-in-IP) и GRE. При использовании GRE с введением IPv6 для администратора практически ничего не меняется, однако поддержки IPv6 в IPIP нет. Вместо IPIP можно использовать IPv6IP. Приятной возможностью GRE является его универсальность, благодаря которой можно переносить протоколы IPv4 и IPv6 как поверх транспортной сети с IPv4, так и поверх сети IPv6. За выбор протокола транспортной сети отвечают ключевые слова ip или ipv6 после команды tunnel mode gre.

Вернёмся к нашей схеме и настроим между двумя маршрутизаторами туннель GRE так, чтобы поверх него работал протокол IPv4, а сам туннель существовал в сети IPv6. Листинг ниже представляет настройку туннельного интерфейса маршрутизатора R1. Устройство R2 конфигурируется аналогично.

R1#sho run int tunnel 1
Building configuration...
Current configuration : 180 bytes
interface Tunnel1
ip address 192.168.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode gre ipv6
tunnel destination 2001:DB8::2
tunnel path-mtu-discovery
end
R1#ping 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/87/120 ms

На сегодняшний день, скорее всего, администратор столкнётся с противоположной ситуацией: потребуется передавать IPv6 трафик поверх сети IPv4. Конфигурация в этом случае симметрична: настройки IPv4 и IPv6 меняются местами. Пожалуй, стоит ещё отметить, что на данный момент в туннелях GRE поверх IPv6 отсутствует поддержка keepalive сообщений.

Кроме перечисленных туннелей существует ещё несколько распространённых типов: 6to4, 6in4, 6rd, Teredo, ISATAP, однако их рассмотрение выходит далеко за рамки данного материала. Сосуществование сетей IPv4 и IPv6 может происходить по одному из трёх сценариев: использование разнообразных туннелей, о которых упоминалось выше, в режиме dual stack, при котором всеми устройствами одновременно поддерживаются обе версии протокола IP, либо при помощи трансляций, например, NAT-PT.

Виртуальные процессы маршрутизации (VRF)

Ещё одна тема, которой хотелось бы коснуться в рамках беглого рассмотрения IPv6 – VRF. Конфигурирование VRF в многопротокольной среде производится немного иначе – без указания ключевого ip в начале. Здесь также используется подход с конструкцией address-family, который мы видели при настройке BGP. При создании VRF используется ключевое слово definition.

R1#conf t
R1(config)#vrf definition test
R1(config-vrf)#rd 1:1
VPN Routing/Forwarding instance configuration commands:
address-family Enter Address Family command mode
default Set a command to its defaults
description VRF specific description
exit Exit from VRF configuration mode
no Negate a command or set its defaults
rd Specify Route Distinguisher
route-target Specify Target VPN Extended Communities
vnet Virtual NETworking configuration
vpn Configure VPN ID as specified in rfc2685
R1(config-vrf)#address-family ?
ipv4 Address family
ipv6 Address family
R1(config-vrf)#address-family ipv6
R1(config-vrf-af)#?
IP VPN Routing/Forwarding instance configuration commands:
default Set a command to its defaults
exit-address-family Exit from vrf address-family configuration submode
export VRF export
import VRF import
inter-as-hybrid Inter AS hybrid mode
maximum Set a limit
mdt Backbone Multicast Distribution Tree
no Negate a command or set its defaults
protection Configure local repair
route-target Specify Target VPN Extended Communities
snmp Modify snmp parameters
R1(config-vrf-af)#^Z
R1#conf t
R1(config-if)#int loo 2
R1(config-if)#vrf forwarding test
R1(config-if)#^Z
R1#sho vrf
Name Default RD Protocols Interfaces
test 1:1 ipv6 Lo2

Добавление протокола маршрутизации в VRF производится также с использованием опции address-family. Добавить в VRF можно не только поименованные процессы, но и пронумерованные.

R1#sho run | sec router
router eigrp test
address-family ipv6 unicast vrf test autonomous-system 1
topology base
exit-af-topology
eigrp router-id 1.1.1.1
exit-address-family
R1#sho run int gi0/0
interface GigabitEthernet0/0
vrf forwarding test
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 address 2001:DB8::1/64
end
R1#sho ipv route vrf test
IPv6 Routing Table - test - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
D 2001:DB8:2::/64 [90/2570240]
via FE80::C80E:21FF:FEE4:8, GigabitEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
R1#sho eigrp address-family ipv6 vrf test neighbors
EIGRP-IPv6 VR(test) Address-Family Neighbors for AS(1)
VRF()
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 10 00:01:53 56 336 0 3
FE80::C80E:21FF:FEE4:8

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

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

Как видно из представленного выше сравнения, поля Identification, Flags и Fragment Offset были удалены.

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

Маршрутизаторы используют следующие адреса на своих интерфейсах со стандартной маской /64.

Маршрутизатор и интерфейс Адрес
R1 Gi0/0 2001:db8:12::1
R2 Gi0/0 2001:db8:12::2
R2 Gi1/0 2001:db8:23::2
R3 Gi1/0 2001:db8:23::3

Сначала удостоверимся, что в IPv6 заголовке на самом деле отсутствуют указанные выше поля, для чего с помощью ICMP протокола убедимся в наличии связности между маршрутизаторами R1 и R3 и изучим содержимое одного из перехваченных на линке R1-R2 пакетов.

R1#ping 2001:db8:23::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/16 ms

Выясним теперь значение MTU для интерфейса Gi0/0 маршрутизатора R1.

R1#sho ipv int gi0/0
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C801:33FF:FEC4:8
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:12::1, subnet is 2001:DB8:12::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FFC4:8
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.

Так как значение MTU для протокола IPv6 равно 1500 байт, то мы не сможем передать ICMP сообщения большего размера. Для того, чтобы это проверить, отправим с помощью команды ping несколько сообщений echo request размером 2000 байт.

R1#ping 2001:db8:23::3 si
R1#ping 2001:db8:23::3 size 2000
Type escape sequence to abort.
Sending 5, 2000-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms

Удивительно, не так ли?! Заглянем в дамп и выясним, что же происходит в сети на самом деле.

В представленном выше пакете IPv6 появился дополнительный заголовок Fragment Header for IPv6, которого не было ранее. Этот дополнительный заголовок и содержит такие важные для процесса фрагментации поля как: Offset, More Fragments и Identification. Таким образом, фрагментация в IPv6 всё-таки возможна и выполняется она отправителем с использованием вспомогательного заголовка Fragment Header for IPv6.

Стоит заметить, что в IPv6 заголовок пакета имеет строго фиксированную длину в 40 байт, а все вспомогательные опции вынесены в последующие заголовки. Данный подход носит название IPv6 header chain. Обратите внимание на значения поля Next Header в заголовке пакета IPv6 и последующем заголовке Fragment Header for IPv6.

Продолжим наши эксперименты и вручную уменьшим значение MTU для маршрутизатора R2 на линке R2-R3.

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int gi1/0
R2(config-if)#ipv mtu ?
<1280-1500> MTU (bytes)
R2(config-if)#ipv mtu 1300
R2(config-if)#do sho ipv int gi1/0 | i MTU
MTU is 1300 bytes

Теперь вновь сгенерируем на маршрутизаторе R1 несколько больших пакетов.

R1#ping 2001:db8:23::3 size 2000
Type escape sequence to abort.
Sending 5, 2000-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
B!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 28/33/36 ms

Первый пакет был потерян, зато все остальные оказались успешно доставленными. Заглянем теперь в дамп трафика. Итак, маршрутизатор R1 сразу же выполняет фрагментацию и отправляет два пакета с размерами 1496 и 560 байт (на картинке ниже поле Length отображает длину кадра Ethernet, заголовок которого составляет 14 байт).

Однако первый пакет не может быть передан через линк R2-R3, о чём маршрутизатор R2 генерирует ICMP сообщение Packet Too Big (Type=2, Code=0). Маршрутизатор R1 реагирует на полученное ICMP-сообщение и начинает отправку данных, используя более мелкие пакеты: 1296 и 760 байт.

Да, протокол IPv4 ведёт себя совершенно иначе: маршрутизатор по пути следования трафика будет просто фрагментировать проходящие IP-пакеты без установленного бита DF, если их размер превышает значение MTU для исходящего интерфейса; и отбрасывать IP-пакеты с установленным битом DF в том же случае. Конечно, промежуточный маршрутизатор будет генерировать ICMP сообщение (Type=2, Code=4) Destination Unreachable (Fragmentation Needed), но отправляющая сторона никак не сможет на них отреагировать из-за выставленного бита DF.

В заключение хотели бы обратить внимание читателя на размеры IPv6 пакетов, которые получались при фрагментации для передачи через канал с IPv6 MTU равным 1300 байт. Пакеты имели размеры 1296 и 760 байт. Но почему именно 1296, а не 1300 байт? Ответ кроется в деталях реализации процедуры фрагментации, а именно в размере поля Offset заголовка Fragment Header for IPv6. Дело в том, что поле Offset имеет длину равную 13 бит и указывает на количество блоков по 8 байт, на которое смещён данный фрагмент. Таким образом, смещение фрагмента должно быть кратным 8 байтам. Аналогичная ситуация наблюдается и в протоколе IPv4, где поле Fragment Offset имеет абсолютно такую же длину.

Заключение

Завершая этот вводный кусочек, хочется отметить следующее.

  1. Администраторам стало сложнее запоминать адресацию своих сетей.
  2. Требуется освоиться с длиннющей записью сетей/хостов в IPv6.
  3. Нужно привыкнуть и освоить автоматический поиск и исследование соседей (маршрутизаторов и конечных станций), смириться с отсутствием широковещания.
  4. Наличие канальной информации об узле сразу в IP-адресе. Протокол ARP (или аналоги) в большинстве случаев более не требуется – вполне достаточно использования EUI-64 для определения хоста.
  5. Не так страшен черт, как его малюют: IP и есть IP – идеологически все очень близко, замена транспорта не существенно влияет на идеологию современных сетей передачи данных.
  6. Использование в IPv6 трансляции сетевых адресов NAT/PAT, довольно ресурсоёмкой операции, в большинстве ситуаций более не требуется.
  7. В сети могут существовать несколько хостов с абсолютно идентичными валидными маршрутизируемыми IPv6 адресами. Это так называемый anycast. Также стоит привыкнуть к наличию на разных интерфейсах маршрутизаторов адресов из одной и той же подсети не маршрутизируемых link-local адресов.
  8. Можно постепенно мигрировать от IPv4 к IPv6, либо поддерживать оба протокола в течение времени, необходимого на глобальный переход к IPv6.
  9. Компания Cisco и другие производители сетевого оборудования уже давно готовы к переходу на IPv6. Дело за администраторами.

Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter

что это такое и как он работает – База знаний Timeweb Community

Протокол сетевого взаимодействия TCP/IPv4 используется для передачи зашифрованных данных в сети интернет и локальных подсетях уже более тридцати лет. На его основании создается и поддерживается уникальная адресация сетевого оборудования (узлов). Еще в начале 90-х годов прошлого века был определен основной недостаток данного протокола – ограничение по количеству возможных ip-адресов, которое не может превысить 4,23 миллиарда. В результате была разработана новая система протоколирования сетевого взаимодействия – интернет-протокол IPv6 (Internet Protocol version 6). Однако массовый переход на более прогрессивную технологию обусловлен некоторыми сложностями. Хотя, например, в Соединенных Штатах уже более половины пользователей применяют именно протокол IPv6.

Основные отличия протоколов IPv4 и IPv6

Как уже было сказано, ключевым недостатком протокола четвертой версии TCP/IPv4 является ограниченная масштабируемость уникальных адресов, присваиваемых для идентификации в сетях взаимодействия. Для создания ip-адресов на уровне программных записей используется 32-х битная система в формате 0.0.0.0 – 255.255.255.255. При построении локальных подсетей вводится дополнительный атрибут «маска подсети», записываемая после символа «/». В результате даже крупные ЛВС, объединенные в Ethernet, чаще всего имеют один публичный ip-адрес, выдаваемый провайдером и закрепленный на уровне шлюза (маршрутизатора). Самостоятельный обмен данными на уровне отдельных устройств частной подсети с выходом в паблик-интернет требует сложного администрирования. Для решения задач маршрутизации, требующих получения статических IP-адресов, понадобятся дополнительные финансовые затраты. 

В интернет-протоколе нового поколения IPv6 для создания адресной маршрутизации используется 128-битная система записи. В IPv6-адресе записи представляют собой восемь 16-битных блоков, разделенных двоеточиями: 2dfc:0:0:0:0217:cbff:fe8c:0. Общее количество ip-адресов, возможных для распределения, может составить в общей сложности 2128 (приблизительно 340 282 366 920 938 000 000 000 000 000 000 000 000). Повсеместное использование данного стандарта позволит полностью решить задачу нехватки сетевых адресов в обозримом будущем. 

С целью упрощения записи адреса в протоколе IPv6 используется вариант сжатия кода, когда смежные последовательности нулевых блоков заменяются парами символов двоеточия. Например, адрес групповой рассылки FFEA:0:0:0:0:CA28:1012:4254 в сжатой форме будет представлен в укороченном виде FFEA::CA28:1012:4254. Данный механизм упрощает процесс записи, хранения и обработки кода. 

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

Впечатляет минимальный диапазон адресов подсети, получаемых пользователем при подключении по протоколу IPv6. Например, при использовании маски подсети «/128» получаем более 256 адресов.

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

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

Дополнительные преимущества протокола IPv6

По сравнению с четвертой версией, в протоколе TCP/IPv6 реализован ряд дополнительных функциональных возможностей: 

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

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

  • в протоколе реализована функция Quality of Service (QoS), позволяющая определять чувствительные к задержке пакеты;

  • при передаче широковещательных пакетов используются многоадресные группы;

  • для реализации технологии мультивещания в IPv6 задействовано встроенное адресное пространство FF00::/8;

  • для повышения безопасности используется поддержка стандарта шифрования IPsec, который позволяет шифровать данные без необходимости какой-либо поддержки со стороны прикладного ПО.

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

Внедрение протокола TCP/IPv6

Несмотря на долгую историю разработки, которая берет начало в 1992 году, тестирование нового протокола состоялось одномоментно 8 июня 2011 года в Международный день IPv6. Эксперимент прошел удачно и предоставил возможность для выработки рекомендаций по дальнейшему совершенствованию данной технологии, ее массовому внедрению.

Первой компанией, внедрившей в 2008 году стандарт протокола IPv6 на постоянной основе, стал Google. Тестирование проводилось в течение четырех лет, было признано успешным. 6 июня 2012 года состоялся Всемирный запуск IPv6. Сегодня мировые лидеры в производстве сетевого оборудования Cisco и D-Link применяют данный сетевой стандарт в своих маршрутизаторах на базовом уровне. В мобильных сетях стандарта LTE поддержка протокола IPv6 является обязательной. IT-компании Google, Facebook, Microsoft и Yahoo используют IPv6 на своих основных web-ресурсах. Протокол получает все большее распространение в корпоративных сетях и при домашнем использовании.

Согласно исследованиям Google, на начало 2020 года доля IPv6 в общемировом сетевом трафике составляла около 30%. В России данный показатель значительно ниже, он составляет приблизительно 4,5% всего трафика. В то же время все большее количество отечественных регистраторов доменов и хостинг-провайдеров переводят свои DNS-серверы на протокол IPv6.

Сложности перехода 

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

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

Фильтрация IPv6-трафика с использованием примера конфигурации «список префиксов»

В этом документе представлен образец конфигурации для списков префиксов IPv6. В этом примере маршрутизаторы R1 и R2 настроены со схемой адресации IPv6 и подключены через последовательный канал. Протокол маршрутизации, включенный на двух маршрутизаторах, — IPv6 OSPF. Для создания сетей в маршрутизаторе R2 настроено 10 адресов обратной связи, и адреса обратной связи, настроенные на обоих маршрутизаторах (R1 и R2), объявляются друг другу с помощью идентификатора процесса ipv6 ospf, идентификатор области, идентификатор области [идентификатор экземпляра ] команда.В этом примере требуется запретить явные маршруты, исходящие от интерфейсов loopback 8 и loopback 9 маршрутизатора R2, которые достигают маршрутизатора R1.

В этом примере конфигурации используется команда ipv6 prefix-list list-name для создания списка префиксов IPv6 с именем ipv6_all_addresses на маршрутизаторе R1.

В этом случае на IPv6 OSPF используйте команду distribute-list prefix-list-name , чтобы применить список префиксов к настроенному протоколу.

Требования

Перед попыткой этой конфигурации убедитесь, что вы соответствуете этим требованиям:

Используемые компоненты

Информация в этом документе основана на маршрутизаторе Cisco серии 7200 с программным обеспечением Cisco IOS ® версии 15.1 (для конфигураций на маршрутизаторах R1 и R2).

Соглашения

См. Раздел Условные обозначения технических советов Cisco для получения информации об условных обозначениях в документе.

В этом разделе представлена ​​информация для настройки функций, описанных в этом документе.

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

Схема сети

В этом документе используется следующая настройка сети:

Конфигурации

В этом документе используются следующие конфигурации:

Маршрутизатор R1
 R1 #  показать рабочую конфигурацию 
версия 15.0
!
имя хоста R1
!
ip cef
!
!
IPv6 одноадресная маршрутизация
 
! - Включает пересылку пакетов IPv6.
 
!
интерфейс Loopback0
 нет IP-адреса
 IPv6-адрес 1111 :: 1/128
 ipv6 ospf 10 область 0
 
! --- Включает OSPFv3 на интерфейсе и связывает! --- интерфейс looback1 с областью 0.
 
!
интерфейс Loopback1
 нет IP-адреса
 IPv6-адрес 2222 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Serial0 / 0
 нет IP-адреса
 IPv6-адрес 1010: 1: 1: 1 :: 11/64
 ipv6 ospf 10 область 0
 тактовая частота 2000000
!
!
маршрутизатор ipv6 ospf 10
 идентификатор маршрутизатора 2.2.2.2
 журнал изменений смежности
   список-префиксов рассылки ipv6_all_addresses в 
 
Применяет список префиксов  ipv6_all_addresses ! --- к OSPF для обновлений маршрутизации IPv6, полученных на интерфейсе. ! --- Используйте эту команду в режиме настройки маршрутизатора.
 
!
ipv6 prefix-list ipv6_all_addresses seq 10 allow AB00 :: 1/128
 
! --- Создает список префиксов с именем  ipv6_all_addresses . ! ---  Seq 10  обозначает порядковый номер настраиваемой записи списка префиксов! ---.! ---  разрешить / запретить  разрешить / запретить сеть! --- что соответствует условию.
 

ipv6 prefix-list ipv6_all_addresses seq 20 allow AB10 :: 1/128
ipv6 prefix-list ipv6_all_addresses seq 30 allow AB20 :: 1/128
список-префиксов ipv6 ipv6_all_addresses seq 40 разрешение AB30 :: 1/128
список-префиксов ipv6 ipv6_all_addresses seq 50 разрешение AB40 :: 1/128
список-префиксов ipv6 ipv6_all_addresses seq 60 разрешение AB50 :: 1/128
список-префиксов ipv6 ipv6_all_addresses seq 70 разрешение AB60 :: 1/128
ipv6 prefix-list ipv6_all_addresses seq 80 разрешить AB70 :: 1/128
  список префиксов ipv6 ipv6_all_addresses seq 90 deny AB80 :: 1/128
список префиксов ipv6 ipv6_all_addresses seq 100 deny AB90 :: 1/128 
 
! --- Отклоняет маршруты AB80 :: 1/128 и AB90 :: 1/128.
!
конец

 

Примечание: Список префиксов имеет следующие ограничения именования:

Маршрутизатор R2
 R2 #  показать рабочую конфигурацию 
версия 15.0
!
имя хоста R2
!
ip cef
!
IPv6 одноадресная маршрутизация
!
интерфейс Loopback0
 нет IP-адреса
 IPv6-адрес AB00 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback1
 нет IP-адреса
 IPv6-адрес AB10 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback2
 нет IP-адреса
 IPv6-адрес AB20 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback3
 нет IP-адреса
 IPv6-адрес AB30 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback4
 нет IP-адреса
 IPv6-адрес AB40 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback5
 нет IP-адреса
 IPv6-адрес AB50 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback6
 нет IP-адреса
 IPv6-адрес AB60 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback7
 нет IP-адреса
 IPv6-адрес AB70 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback8
 нет IP-адреса
 IPv6-адрес AB80 :: 1/128
 ipv6 ospf 10 область 0
!
интерфейс Loopback9
 нет IP-адреса
 IPv6-адрес AB90 :: 1/128
 ipv6 ospf 10 область 0

!
интерфейс Serial0 / 0
 нет IP-адреса
 IPv6-адрес 1010: 1: 1: 1 :: 10/64
 ipv6 ospf 10 область 0
 тактовая частота 2000000
!
ip forward-protocol nd
!
!
маршрутизатор ipv6 ospf 10
 идентификатор маршрутизатора 1.1.1.1
 журнал изменений смежности
!
конец

 

Для проверки маршрутов, полученных маршрутизатором R1, используйте команду show ipv6 route ospf .

показать маршрут ipv6 ospf
В маршрутизаторе R1
 R1 #  показать маршрут ipv6 ospf 
Таблица маршрутизации IPv6 - 13 записей
Коды: C - подключен, L - локальный, S - статический, R - RIP, B - BGP.
       U - Статический маршрут для каждого пользователя, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS между областями, IS - сводка ISIS
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP внешний
O AB00 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB10 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB20 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB30 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB40 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB50 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB60 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
OI AB70 :: 1/128 [110/64]
     через FE80 :: C007: EFF: FE58: 0, Serial0 / 0
 
! --- Обратите внимание, что маршруты AB80 :: 1/128 и AB90 :: 1/128! --- исходящие из lo 8 и lo 9, здесь не перечислены.
 

Для отображения информации о списке префиксов IPv6 или записях списка префиксов используйте команду show ipv6 prefix-list detail .

показать список префиксов ipv6
В маршрутизаторе R1
 R1 #  показать подробный список префиксов ipv6 
Список префиксов с последним удалением / вставкой: ipv6_all_addresses
список префиксов ipv6 ipv6_all_addresses:
   количество: 10, количество записей: 0, последовательности: 10 - 100, количество ссылок: 3
   seq 10 разрешает AB00 :: 1/128 (количество совпадений: 1, количество ссылок: 5)
   seq 20 разрешает AB10 :: 1/128 (количество совпадений: 1, количество ссылок: 1)
   seq 30 allow AB20 :: 1/128 (количество совпадений: 1, количество ссылок: 2)
   seq 40 allow AB30 :: 1/128 (количество совпадений: 1, количество ссылок: 1)
   seq 50 allow AB40 :: 1/128 (количество совпадений: 1, количество ссылок: 3)
   seq 60 разрешает AB50 :: 1/128 (количество совпадений: 1, количество ссылок: 1)
   seq 70 разрешает AB60 :: 1/128 (количество совпадений: 1, количество ссылок: 2)
   seq 80 разрешает AB70 :: 1/128 (количество совпадений: 1, количество ссылок: 1)
   seq 90 deny AB80 :: 1/128 (количество совпадений: 1, количество ссылок: 2)
   seq 100 deny AB90 :: 1/128 (количество совпадений: 1, счетчик ссылок: 1) 
 R1 #  показать сводку списка префиксов ipv6 
Список префиксов с последним удалением / вставкой: ipv6_all_addresses
список префиксов ipv6 ipv6_all_addresses:
   количество: 10, количество записей: 0, последовательности: 10 - 100, количество ссылок: 3
 
! --- Эта команда отображает подробную или! --- сводную информацию обо всех списках префиксов IPv6.
 

Средство интерпретации выходных данных (только для зарегистрированных клиентов) (OIT) поддерживает определенные команды show . Используйте OIT для просмотра анализа выходных данных команды show .

В настоящее время для этой конфигурации нет специальной информации по поиску и устранению неисправностей.

Интернет-протокол версии 6 Адресное пространство

[1]
 :: 1/128 зарезервировано для адреса обратной связи [RFC4291].Зарезервировано протоколом. Для официальной регистрации см. [Реестр IANA  iana-ipv6-special-registry ]. 
[2]
 :: / 128 зарезервировано для неопределенного адреса [RFC4291].
Зарезервировано протоколом. Для официальной регистрации см. [Реестр IANA  iana-ipv6-special-registry ]. 
[3]
 :: ffff: 0: 0/96 зарезервировано для отображаемого IPv4-адреса [RFC4291].Зарезервировано протоколом. Для официальной регистрации см. [Реестр IANA  iana-ipv6-special-registry ]. 
[4]
 0 :: / 96 не рекомендуется [RFC4291]. Ранее определялся как префикс «IPv4-совместимый IPv6-адрес». 
[5]
 «Хорошо известный префикс» 64: ff9b :: / 96 используется в алгоритмическом отображении между адресами IPv4 и IPv6 [RFC6052].
[6]
 64: ff9b: 1 :: / 48 зарезервировано для локального преобразования IPv4 / IPv6 [RFC8215]. 
[7]
 2001: 0 :: / 23 зарезервировано для назначения протокола IETF [RFC2928].
Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[8]
 2001: 0 :: / 32 зарезервировано для TEREDO [RFC4380].Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[9]
 2001: 2 :: / 48 зарезервировано для тестирования [RFC5180] [RFC Errata 1752].
Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[10]
 2001: 3 :: / 32 зарезервировано для AMT [RFC7450].Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[11]
 2001: 4: 112 :: / 48 зарезервировано для AS112-v6 [RFC7535].
Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[12]
 2001: 10 :: / 28 устарело (ранее ORCHID) [RFC4843].Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[13]
 2001: 20 :: / 28 зарезервировано для ORCHIDv2 [RFC7343].
Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[14]
 2001: db8 :: / 32 зарезервировано для документации [RFC3849].Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 
[15]
 2002 :: / 16 зарезервировано для 6to4 [RFC3056].
Для получения полной информации о регистрации см. [IANA Registry  iana-ipv6-special-registry ]. 

Настройка IPv6 для опытных пользователей — Windows Server

  • 4 минуты на чтение

В этой статье

В этой статье представлены решения для настройки интернет-протокола версии 6 (IPv6) для опытных пользователей в Windows.

Исходная версия продукта: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 929852

Сводка

Таблица префиксов используется для определения того, какой адрес использовать, когда для имени системы доменных имен (DNS) доступно несколько адресов.

По умолчанию Windows предпочитает глобальные одноадресные IPv6-адреса адресам IPv4.

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

Важно

IPv6 является обязательной частью Windows Vista и Windows Server 2008 и более новых версий. Мы не рекомендуем отключать IPv6 или его компоненты. В противном случае некоторые компоненты Windows могут не работать.

Мы рекомендуем использовать Prefer IPv4 over IPv6 в политиках префиксов вместо отключения IPV6.

Используйте раздел реестра для настройки IPv6

Важно

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

Метод 1. Используйте значение реестра для настройки IPv6

Чтобы настроить IPv6, измените это значение реестра в соответствии с таблицей ниже:

Расположение : HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip6 \ Parameters \
Имя : DisabledComponents
Тип : REG_DWORD
Мин. Значение : 0x4 Макс. Значение
IP

Функции IPv6 Значение реестра и комментарии
Предпочитать IPv4 IPv6 Dec 32
Hex 0x20
Bin xx1x xxxx

Рекомендуется вместо отключения IPv6.

Отключить IPv6 Дек 255
Hex 0xFF
Bin 1111 1111

См. Задержку запуска после отключения IPv6 в Windows, если вы столкнулись с задержкой запуска после отключения IPv6 в Windows 7 SP1 или Windows Server 2008 R2 SP1.

Кроме того, запуск системы будет отложен на пять секунд, если IPv6 отключен из-за неправильного отключения параметра реестра «Отключенные компоненты» на значение 0xfffffff. Правильное значение должно быть 0xff. Для получения дополнительной информации см. Обзор Интернет-протокола версии 6 (IPv6).

Значение реестра «Отключенные компоненты» не влияет на состояние флажка. Даже если в разделе реестра «Отключенные компоненты» задано отключение IPv6, можно установить флажок на вкладке «Сеть» для каждого интерфейса. Это ожидаемое поведение.

Отключить IPv6 на всех нетуннельных интерфейсах Dec 16
Hex 0x10
Bin xxx1 xxxx
Отключить IPv6 на всех туннельных интерфейсах Дек 1
Hex 0x01
Bin xxxx xxx1
Отключить IPv6 на всех нетуннельных интерфейсах (кроме loopback) и на туннельном интерфейсе IPv6 Dec 17
Hex 0x11
Bin xxx1 xxx1
Предпочитать IPv6 IPv4 Корзина xx0x xxxx
Повторно включить IPv6 на всех нетуннельных интерфейсах Корзина xxx0 xxxx
Повторно включить IPv6 на всех туннельных интерфейсах Корзина xxx xxx0
Повторно включить IPv6 на нетуннельных интерфейсах и на туннельных интерфейсах IPv6 Корзина xxx0 xxx0

Примечание

  • Администраторы должны создать.admx, чтобы отобразить параметры на шаге 5 в параметре групповой политики.
  • Чтобы изменения вступили в силу, необходимо перезагрузить компьютер.
  • Значения, отличные от 0 или 32, вызывают сбой службы маршрутизации и удаленного доступа после того, как это изменение вступит в силу.

По умолчанию протокол туннелирования 6to4 включен в Windows Vista, Windows Server 2008 или более поздних версиях, когда интерфейсу назначается общедоступный IPv4-адрес (любой IPv4-адрес, не входящий в диапазон 10.0.0.0 / 8, 172.16.0.0/12 или 192.168.0.0/16). 6to4 автоматически назначает IPv6-адрес интерфейсу туннелирования 6to4 для каждого адреса, а 6to4 динамически регистрирует эти IPv6-адреса на назначенном DNS-сервере. Если такое поведение нежелательно, мы рекомендуем отключить туннельные интерфейсы IPv6 на затронутых хостах.

Метод 2: используйте командную строку для настройки IPv6

Вы также можете выполнить следующие действия, чтобы изменить раздел реестра:

  1. Откройте административное окно командной строки .

  2. Выполните следующую команду:

      reg добавить «HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip6 \ Parameters» / v DisabledComponents / t REG_DWORD / d <значение> / f
      

    Примечание

    Замените <значение> соответствующим значением из предыдущей таблицы.

Как рассчитать значение реестра

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

В этой таблице перечислены компоненты, которыми управляет каждый бит (от низкого к высокому):

Туннель Отключить туннельные интерфейсы
Туннель 6to4 Отключить интерфейсы 6to4
Туннель Isatap Отключить интерфейсы Isatap
Туннель Тередо Отключить интерфейсы Teredo
Родной Отключить собственные интерфейсы (также PPP)
PreferIpv4 Предпочитать IPv4 в политике префиксов по умолчанию
TunnelCp Отключить интерфейсы CP
TunnelIpTls Отключить интерфейсы IP-TLS

Для каждого бита 0 означает ложь, а 1 означает истину.См. Пример в этой таблице:

Предпочитать IPv4 IPv6 в политиках префиксов Отключить IPv6 на всех нетуннельных интерфейсах Отключить IPv6 на всех туннельных интерфейсах Отключить IPv6 на нетуннельных интерфейсах (кроме loopback) и на туннельном интерфейсе IPv6
Отключить туннельные интерфейсы 0 0 1 1
Отключить интерфейсы 6to4 0 0 0 0
Отключить интерфейсы Isatap 0 0 0 0
Отключить интерфейсы Teredo 0 0 0 0
Отключить собственные интерфейсы (также PPP) 0 1 0 1
Предпочитать IPv4 в политике префиксов по умолчанию. 1 0 0 0
Отключить интерфейсы CP 0 0 0 0
Отключить интерфейсы IP-TLS 0 0 0 0
Двоичный 0010 0000 0001 0000 0000 0001 0001 0001
Шестнадцатеричный 0x20 0x10 0x01 0x11

Номер ссылки

Для получения информации о RFC 3484 см. Выбор адреса по умолчанию для Интернет-протокола версии 6 (IPv6).

Для получения дополнительной информации о том, как установить приоритет IPv4 над IPv6, см. Использование SIO_ADDRESS_LIST_SORT.

Для получения информации о RFC 4291 см. Архитектура адресации IP версии 6.

Для получения дополнительной информации о связанных проблемах см .:

Дополнительные сведения об инструментах сетевой трассировки см .:

моделей делегирования префикса IPv6

модели делегирования префикса IPv6

Модели делегирования префикса IPv6
draft-templin-v6ops-pdhost-17.txt

Префиксы IPv6

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

Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.

Internet-Drafts являются рабочими документами Инженерной группы Интернета (IETF). Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов находится по адресу https: // datatracker.ietf.org/drafts/current/.

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

Срок действия этого Интернет-проекта истекает 17 июня 2018 г.

Авторские права (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

Этот документ регулируется BCP 78 и Правовыми положениями IETF Trust, касающимися документов IETF (https: // trustee.ietf.org/license-info), действующий на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать текст упрощенной лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.


IPv6 Prefix Delegation (PD) влечет за собой 1) передачу префикса от делегирующего маршрутизатора к запрашивающему маршрутизатору, 2) представление префикса в таблице маршрутизации делегирующего маршрутизатора и 3) службу обмена управляющими сообщениями между делегирующим и запрашивающим маршрутизаторами. Маршрутизаторы для поддержания срока службы префиксов.После делегирования префикс доступен для исключительного использования запрашивающим маршрутизатором и не передается никаким другим узлам. В этом документе рассматриваются модели делегирования префикса, в которых запрашивающий маршрутизатор является узлом, который действует как маршрутизатор от имени любых нисходящих сетей, как хост от имени своих локальных приложений или как оба.

Запрашивающий маршрутизатор явно запрашивает делегирование префиксов через маршрутизатор делегирования по каналу. Маршрутизатор-делегат может размещать службу делегирования префикса локально или может пересылать запросы делегирования префикса в поддерживающую инфраструктуру, расположенную в другом месте в сети оператора (например,г. как в модели агента ретрансляции DHCPv6 [RFC3315] [RFC3633]). Однако независимо от того, где находится фактический сервер делегирования префиксов, делегирующий маршрутизатор предоставляет сервису интерфейс первого перехода запрашивающего маршрутизатора. В следующих параграфах представлены модели делегирования префиксов.

Для узлов, которые подключаются к нисходящим сетям (например, сотовый телефон, который подключает «привязанную» сеть Интернета вещей (IoT), сервер, на котором размещается сложная внутренняя сеть виртуальных машин и т. Д.) делегирующий маршрутизатор ‘D’ делегирует префикс ‘P’ запрашивающему маршрутизатору ‘R’, как показано на рисунке 1:

 .--.
                                                 , - () -.
                                               (_ Оператор)
                                 + -----------> (__ Сеть)
                                 | `- (_______) - '
                     + ----------- + --------- +
                     | Делегирующий маршрутизатор 'D' |
                     | (Делегат «П») |
                     + ---------- + ---------- +
                                |
                                | Ссылка на восходящий поток
                                |
                     + ---------- + ---------- +
                     | Восходящий интерфейс |
                     + --------------------- +
                     | |
                     | Запрос маршрутизатора 'R' |
                     | (Получите "P") |
                     | |
                     + - + - + - + - + - + ----- + - +
                     | A1 | | A2 | | A3 | ... | Aj |
                     + - + - + - + - + - + ----- + - +
                     | Нисходящий интерфейс |
                     + ---------- + ---------- +
                                |
                                | Ссылка на нисходящий поток
                                |
    X ---- + ------------- + -------- + ---- + --------------- + ---ИКС
         | | | |
    + --- ++ - + - + + --- ++ - + - + + --- ++ - + - + + --- ++ - + - +
    | | Ак | | | | Al | | | | Am | | | | A * | |
    | + - + | | + - + | | + - + | | + - + |
    | Хост h2 | | Хост h3 | | Хост h4 | ... | Host Hn |
    + --------- + + --------- + + --------- + + --------- +

       <-------------- Сеть нисходящего потока ------------->
 

Рисунок 1: Классическая модель маршрутизации

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

«R» может затем работать в рамках модели слабой конечной системы (также известной как «слабый хост») [RFC1122] [RFC8028], назначая адреса, взятые из «P», виртуальному интерфейсу, как показано на рисунке 2:

.-.
                                                 , - () -.
                                               (_ Оператор)
                                 + -----------> (__ Сеть)
                                 | `- (_______) - '
                     + ----------- + --------- +
                     | Делегирующий маршрутизатор 'D' |
                     | (Делегат «П») |
                     + ---------- + ---------- +
                                |
                                | Ссылка на восходящий поток
                                |
                     + ---------- + ---------- +
                     | Восходящий интерфейс |
                     + --------------------- +
                     | |
                     | Запрашивающий узел "R" |
                     | (Получите "P") |
                     | |
                     + - + - + - + - + - + ----- + - +
                     | A1 | | A2 | | A3 | ... | An |
                     + - + - + - + - + - + ----- + - +
                     | Виртуальный интерфейс |
                     + --------------------- +
 

Рисунок 2: Модель системы со слабым концом

«R» вместо этого может функционировать в рамках модели сильной конечной системы (также известной как «сильный хост») [RFC1122] [RFC8028] путем назначения адресов IPv6, взятых из «P», восходящему интерфейсу, как показано на рисунке 3:

 .--.
                                                 , - () -.(_ Оператор)
                                 + -----------> (__ Сеть)
                                 | `- (_______) - '
                     + ----------- + --------- +
                     | Делегирующий маршрутизатор 'D' |
                     | (Делегат «П») |
                     + ---------- + ---------- +
                                |
                                | Ссылка на восходящий поток
                                |
                     + ---------- + ---------- +
                     | Восходящий интерфейс |
                     + - + - + - + - + - + ----- + - +
                     | A1 | | A2 | | A3 | ... | An |
                     + - + - + - + - + - + ----- + - +
                     | |
                     | Запрашивающий узел "R" |
                     | (Получите "P") |
                     | |
                     + --------------------- +
                     | Виртуальный интерфейс |
                     + --------------------- +
 

Рисунок 3: Модель сильной оконечной системы

В следующих разделах представлены соображения для узлов, использующих механизмы IPv6 PD.

Применяется терминология нормативных ссылок, а термины «узел», «хост» и «маршрутизатор» такие же, как определено в [RFC8200].

Для целей данного документа определены следующие термины:

общий префикс

— префикс IPv6, который может быть объявлен более чем одному узлу в канале связи, например, в сообщении «Объявление маршрутизатора» (RA) «Опция информации о префиксе» (PIO) [RFC4861]. Маршрутизатор, объявляющий префикс, должен рассматривать префикс как подключенный, чтобы функция разрешения адресов IPv6 Neighbor Discovery (ND) определяла правильного соседа для каждого пакета.
индивидуальный префикс

— префикс IPv6, который объявляется ровно одному узлу в канале связи, при этом узел может не знать, что префикс индивидуален, и не может участвовать в процедурах обслуживания префикса. Маршрутизатор, объявляющий префикс, может рассматривать его как подключенный или не подключенный. В первом случае маршрутизатор выполняет разрешение адресов и пересылает только те пакеты, которые соответствуют одному из настроенных адресов узла, так что узел не будет получать нежелательные пакеты.В последнем случае маршрутизатор может просто перенаправить все пакеты, соответствующие префиксу, на узел, который затем должен отбросить все пакеты, не соответствующие одному из его настроенных адресов. Пример службы индивидуальных префиксов задокументирован в [RFC8273].
делегированный префикс

— префикс IPv6, который явно передается узлу для его собственного исключительного использования, где узел является активным участником делегирования префикса и процедур обслуживания. Делегирующий маршрутизатор просто пересылает все пакеты, соответствующие префиксу, запрашивающему узлу.Запрашивающий узел связывает префикс с нисходящим и / или внутренним виртуальными интерфейсами (т.е., а не с восходящим интерфейсом). Примером службы IPv6 PD является протокол динамической конфигурации хоста для IPv6 (DHCPv6) [RFC3315] [RFC3633]. Также была предложена альтернативная услуга, основанная исключительно на обмене сообщениями IPv6 ND [I-D.pioxfolks-6man-pio-exclusive-bit].

IPv6 позволяет узлам назначать несколько адресов одному интерфейсу. В [RFC7934] обсуждаются варианты многоадресной адресации, а также варианты использования, в которых может быть желательна многоадресная адресация.Опции конфигурации адреса для множественной адресации включают автоконфигурацию адреса без сохранения состояния (SLAAC) [RFC4862], конфигурацию адреса DHCPv6 [RFC3315], ручную настройку и т. Д.

Узлы

настраивают адреса из общего или индивидуального префикса и назначают их восходящему интерфейсу, по которому был получен префикс. Когда узел назначает адреса, необходимо использовать обнаружение многоадресного прослушивателя (MLD) [RFC3810], чтобы присоединиться к соответствующей группе (группам) многоадресной рассылки запрошенного узла и использовать алгоритм обнаружения повторяющегося адреса (DAD) [RFC4862], чтобы гарантировать, что ни один другой узел не настраивает повторяющийся адрес.

Напротив, узел, который настраивает адреса из делегированного префикса, может назначать их без вызова MLD / DAD на восходящем интерфейсе, поскольку префикс был делегирован узлу для его собственного исключительного использования и не используется совместно с другими узлами.

Когда узел получает делегированный префикс, у него есть много альтернатив для предоставления префикса своим локальным интерфейсам и / или нисходящим сетям. В [RFC7278] обсуждаются альтернативы для предоставления префикса, полученного устройством пользовательского оборудования (UE) в рамках модели обслуживания Программы партнерства третьего поколения (3GPP).В этом документе рассматривается более общий случай, когда узел получает делегированный префикс, явно предоставленный для его собственного исключительного использования.

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

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

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

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

Узлы, которые действуют в соответствии с моделями слабого / сильного хоста, как обсуждалось в предыдущем разделе, автоматически настраивают адреса из делегированных префиксов в соответствии с разделом 6 требований к узлам IPv6 [I-D.ietf-6man-rfc6434-bis].

Как получатель делегированного префикса, узел также должен распознавать адрес Anycast маршрутизатора подсети [RFC4291]. Следовательно, использование узлом адреса Anycast маршрутизатора подсети должно быть неотличимо от поведения обычного маршрутизатора при просмотре из внешнего мира.

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

Когда узел настраивает адреса для себя из делегированного префикса, он может настраивать столько адресов, сколько хочет, но не выполняет MLD / DAD ни для одного из адресов через восходящие интерфейсы.Это означает, что узел может настроить произвольное количество адресов, не вызывая многоадресный обмен сообщениями через восходящий интерфейс, который мог бы мешать другим узлам.

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

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

Когда узел получает общий или индивидуальный префикс с «L = 1» и имеет пакет для отправки в пункт назначения IPv6 внутри префикса, необходимо использовать функцию разрешения IPv6 ND-адресов через восходящий интерфейс для разрешения связи — адрес уровня соседа, который настраивает адрес.Когда узел получает общий или индивидуальный префикс с «L = 0″ и имеет пакет для отправки в пункт назначения IPv6 внутри префикса, если адрес не является одним из собственных адресов узла, он отправляет пакет маршрутизатору по умолчанию, поскольку » L = 0 «не делает никаких заявлений о свойствах префикса на связи или вне связи [RFC4861].

Когда узел получает делегированный префикс, он действует как простой хост для отправки сообщений запроса маршрутизатора (RS) через восходящие интерфейсы (то есть так же, как описано в разделе 4.2 [RFC7084]), но также устанавливает флаг «Router» в значение TRUE в своих сообщениях Neighbor Advertising. Узел рассматривает восходящие интерфейсы как нерекламирующие интерфейсы [RFC4861], то есть он не отправляет сообщения RA через восходящие интерфейсы. Узел также не выполняет функцию разрешения адресов IPv6 ND через восходящие интерфейсы, поскольку делегированный префикс по определению не должен быть связан с восходящим интерфейсом.

Во всех случаях текущий маршрутизатор первого перехода может отправить сообщение перенаправления, которое обновляет кэш соседа узла, чтобы будущие пакеты могли использовать лучший узел первого перехода на ссылке.Перенаправление может применяться либо к одноэлементному адресу назначения, либо ко всему префиксу назначения, как описано в [I-D.templin-6man-rio-redirect].

Протокол управляющих сообщений Интернета для IPv6 (ICMPv6) включает в себя набор типов управляющих сообщений [RFC4443], включая пункт назначения недоступен (DU).

Согласно [RFC4443], маршрутизаторы должны возвращать сообщения DU (с учетом ограничения скорости) с кодом 0 («Нет маршрута к месту назначения»), когда прибывает пакет, для которого нет соответствующей записи в таблице маршрутизации, и с кодом 3 ( «Адрес недоступен»), когда адрес назначения IPv6 не может быть определен.

Согласно [RFC4443], хосты должны возвращать сообщения DU (с учетом ограничения скорости) с кодом 3 внутренним приложениям, когда адрес назначения IPv6 не может быть разрешен, и с кодом 4 («Порт недоступен»), если адрес назначения IPv6 равен единице. собственных адресов, но у транспортного протокола нет слушателя.

Узлы, которые получают и управляют делегированными префиксами в соответствии с этим документом, соблюдают те же процедуры, что описаны выше для маршрутизаторов и хостов.

В этом документе не рассматриваются вопросы IANA.

К этому документу относятся соображения безопасности для обнаружения соседей IPv6 [RFC4861] и любые применимые механизмы PD. Узлы, получающие делегированные префиксы, не выполняют процедуры MLD / DAD на своих восходящих интерфейсах, что означает, что они не могут способствовать перегрузке многоадресного обмена сообщениями на восходящем канале. Кроме того, маршрутизаторы, которые делегируют префиксы, хранят только одну запись в кэше соседей для каждого получателя делегирования префиксов, что означает, что соседний кэш маршрутизатора не может подвергаться атакам на исчерпание ресурсов.

Для общих и индивидуальных префиксов, если маршрутизатор, который объявляет префикс, считает префикс подключенным, функция разрешения IPv6-адресов ND предотвратит попадание нежелательных IPv6-пакетов на узел. Для делегированных префиксов и отдельных префиксов, которые не считаются подключенными к каналу, маршрутизатор доставляет все пакеты, соответствующие префиксу, на одноадресный адрес канального уровня узла (т. Е. Как определено разрешением локального адреса канала), даже если они не соответствуют ни одному из настроенных адресов узла.В последнем случае узел может получать нежелательные пакеты IPv6 через восходящий интерфейс, которые не соответствуют ни настроенному адресу IPv6, ни транспортному приемнику. Затем узел отбрасывает пакеты и наблюдает за процедурами «Пункт назначения недоступен — адрес / порт недоступен», описанными в разделе 9.

Узел также может получать пакеты IPv6 через восходящий интерфейс, которые не соответствуют ни одному из делегированных префиксов узла. В этом случае узел отбрасывает пакеты и соблюдает процедуры «Пункт назначения недоступен — нет маршрута к пункту назначения», описанные в разделе 9.Отбрасывание пакетов необходимо, чтобы избежать атаки отражения, которая заставит узел пересылать пакеты, полученные от восходящего интерфейса, через тот же или другой восходящий интерфейс.

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

Эта работа была мотивирована обсуждениями списка v6ops. Марк Смит указал на необходимость учитывать MLD, а также DAD для назначения адресов интерфейсам. Рикардо Пелаэс-Негро, Эдвин Кордейро, Фред Бейкер, Навин Лакшман, Оле Троан, Боб Хинден, Брайан Карпентер, Джоэл Халперн, Альберт Манфреди, Душан Мудрик и Пол Маркс предоставили полезные комментарии, которые значительно улучшили документ.

Эта работа согласована с программой NASA Safe Autonomous System Operation (SASO) в соответствии с номером контракта NASA NNA16BD84C.

Эта работа согласована с FAA в соответствии с номером контракта SE2025 DTFAWA-15-D-00030.

Эта работа согласована с программой Boeing Information Technology (BIT) MobileNet и программой автономии предприятий Boeing Research & Technology (BR&T).

[RFC0791] Постел, Дж., «Интернет-протокол», STD 5, RFC 791, DOI 10.17487 / RFC0791, сентябрь 1981 г.
[RFC3315] Дромс, Р., Bound, J., Volz, B., Lemon, T., Perkins, C. и M. Carney, «Протокол динамической конфигурации хоста для IPv6 (DHCPv6)», RFC 3315, DOI 10.17487 / RFC3315, июль 2003 г.
[RFC3633] Троан, О. и Р. Дромс, «Параметры префикса IPv6 для протокола динамической конфигурации хоста (DHCP) версии 6», RFC 3633, DOI 10.17487 / RFC3633, декабрь 2003 г.
[RFC3810] Вида, Р. и Л. Коста, «Обнаружение многоадресного прослушивателя версии 2 (MLDv2) для IPv6», RFC 3810, DOI 10.17487 / RFC3810, июнь 2004 г.
[RFC4443] Конта, А., Диринг, С. и М. Гупта, «Протокол управляющих сообщений Интернета (ICMPv6) для спецификации Интернет-протокола версии 6 (IPv6)», STD 89, RFC 4443, DOI 10.17487 / RFC4443, март 2006 г.
[RFC4861] Нартен, Т., Нордмарк, Э., Симпсон, В. и Х. Солиман, «Обнаружение соседей для IP версии 6 (IPv6)», RFC 4861, DOI 10.17487 / RFC4861, сентябрь 2007 г.
[RFC4862] Томсон, С., Нартен, Т. и Т. Джинмей, «Автоконфигурация IPv6 адреса без сохранения состояния», RFC 4862, DOI 10.17487 / RFC4862, сентябрь 2007 г.
[RFC8200] Диринг, С. и Р. Хинден, «Спецификация Интернет-протокола, версия 6 (IPv6)», STD 86, RFC 8200, DOI 10.17487 / RFC8200, июль 2017 г.
[I-D.ietf-6man-rfc6434-bis] Чоун, Т., Лафни, Дж. И Т. Винтерс, «Требования к узлу IPv6», Internet-Draft draft-ietf-6man-rfc6434-bis-02, октябрь 2017 г.
[I-D.pioxfolks-6man-pio-exclusive-bit] Клайн, Э. и М. Абрахамссон, «Флаг исключения опции информации о префиксе объявления маршрутизатора IPv6», Internet-Draft draft-pioxfolks-6man-pio-exclusive-bit-02, март 2017 г.
[I-D.templin-6man-rio-redirect] Темплин Ф. и Дж. woodyatt, «Параметры информации о маршруте в IPv6 Neighbor Discovery», Internet-Draft draft-templin-6man-rio-redirect-05, октябрь 2017 г.
[RFC1122] Брейден, Р., «Требования к хостам Интернета — уровни связи», STD 3, RFC 1122, DOI 10.17487 / RFC1122, октябрь 1989 г.
[RFC4291] Хинден, Р. и С. Диринг, «Архитектура адресации IP версии 6», RFC 4291, DOI 10.17487 / RFC4291, февраль 2006 г.
[RFC7084] Сингх, Х., Биби, В., Донли, К. и Б. Старк, «Основные требования к клиентским пограничным маршрутизаторам IPv6», RFC 7084, DOI 10.17487 / RFC7084, ноябрь 2013 г.
[RFC7278] Бирн, К., Дроун, Д. и А. Виздал, «Расширение префикса IPv6 / 64 из мобильного интерфейса проекта партнерства третьего поколения (3GPP) на канал LAN», RFC 7278, DOI 10.17487 / RFC7278, июнь 2014 г.
[RFC7934] Колитти, Л., Серф, В., Чешир, С. и Д. Шинази, «Рекомендации по доступности адресов хоста», BCP 204, RFC 7934, DOI 10.17487 / RFC7934, июль 2016 г.
[RFC8028] Бейкер, Ф. и Б. Карпентер, «Выбор маршрутизатора первого перехода хостами в сети с несколькими префиксами», RFC 8028, DOI 10.17487 / RFC8028, ноябрь 2016 г.
[RFC8273] Бжозовски, Дж. И Г. Ван де Велде, «Уникальный префикс IPv6 для каждого хоста», RFC 8273, DOI 10.17487 / RFC8273, декабрь 2017 г.

Изменения с -16 на -17:

  • добавлен вспомогательный текст во введении, чтобы обсудить отношения делегирующего маршрутизатора с запрашивающим маршрутизатором и с поддержкой внутренней структуры в сети оператора
  • — обновленные цифры во введении, включая представление сети оператора
  • добавлен новый раздел по вопросам автоконфигурации адреса
Фред Л.Templin (редактор) Templin Boeing Research & Technology P.O. Box 3707 Сиэтл, WA 98124 Соединенные Штаты Америки Электронная почта: [email protected]
.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *