Компания
86,47
рейтинг
28 ноября 2014 в 10:00

Разработка → IPv6 под прицелом



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


Кратко про темпы роста


Если изучить графики, которые предоставляет региональный регистратор IP-адресов и автономных систем, то можно обнаружить, что по состоянию на первое сентября 2014 года количество зарегистрированных IPv6 автономных систем уже перевалило за 20%. На первый взгляд, это серьезная цифра. Но если брать во внимание только реальное количество IPv6-трафика в мире, то сейчас это около 6% от всего мирового интернет-трафика, хотя буквально три года назад было всего 0,5%.


Рис. 1. Реальные объемы IPv6-трафика

По самым скромным оценкам ожидается, что к концу 2015 года доля IPv6-трафика дойдет как минимум до 10%. И рост будет продолжаться. Кроме того, недавно вступил в силу специальный протокол для региональных регистраторов. Теперь новый блок IPv4-адресов будет выдан только в том случае, если компания докажет, что уже внедрила у себя IPv6. Поэтому если кому-то потребуется подсеть белых IPv4-адресов — придется внедрять IPv6. Этот факт также послужит дальнейшему росту IPv6-систем и увеличению трафика. Что же касается рядовых пользователей, то уже по всему миру начали проявляться провайдеры, которые предоставляют конечным абонентам честные IPv6-адреса. Поэтому IPv6 будет встречаться все чаще и чаще, и мы не можем оставить это без внимания.

Что нового в IPv6?


Первое, что бросается в глаза, — это адреса. Они стали длиннее, записываются в шестнадцатеричном виде и сложно запоминаются. Хотя, поработав некоторое время с IPv6, обнаруживаешь, что адреса в целом запоминаемые, особенно если используются сокращенные формы записи. Напомню, что IPv4 использует 32-битные адреса, ограничивающие адресное пространство 4 294 967 296 (2^32) возможными уникальными адресами. В случае же IPv6 под адрес уже выделено 128 бит. Соответственно, адресов доступно 2^128. Это примерно по 100 адресов каждому атому на поверхности Земли. То есть адресов должно хватить на достаточно длительное время.

Адреса записываются в виде восьми групп шестнадцатеричных значений. Например, IPv6-адрес может выглядеть как 2001:DB8:11::1. Важно отметить, что IPv6-адресов на одном интерфейсе может быть несколько, причем это стандартная ситуация. Например, на интерфейсе может быть частный адрес, белый адрес и еще по DHCPv6 приедет дополнительный адрес. И все будет штатно работать, для каждой задачи будет использоваться свой адрес. Если нужно выйти в мир, то будет использоваться белый адрес. Надо до соседнего сервера? Пойдет через частный адрес. Все это будет решаться обычным анализом поля destination.

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

Link local адрес назначается автоматически, как только хост выходит онлайн, чем-то отдаленно такие адреса похожи на механизм APIPA в ОС Windows. Такой адрес всегда начинается с FE80, ну а последние 64 бита — это мак-адрес с FFFE, вставленными посередине, плюс один бит инвертируется. Механизм формирования такого адреса еще называется EUI-64. В итоге адрес будет уникальный, так как мак-адреса обычно отличаются у всех хостов. Но некоторые ОС используют рандомный идентификатор вместо механизма EUI-64.

Что еще нового


Только адресами изменения, естественно, не заканчиваются. Еще был значительно упрощен заголовок (см. рис. 2).


Рис. 2. Сравнение заголовков IPv6 и IPv4

Теперь все, что не является обязательным для маршрутизации пакета из точки в А в точку Б, стало опциональным. А раз опциональное — значит, переезжает в extension header, который лежит между IPv6-заголовком и TCP/UDP-данными. В этом самом extension-заголовке уже и проживают фрагментирование, IPsec, source routing и множество другого функционала.

Резко упростили задачу маршрутизаторам, ведь уже не надо пересчитывать контрольные суммы, и в итоге IPv6 обрабатывается быстрее, чем IPv4. Контрольные суммы убрали вовсе. Во-первых, у фрейма на уровне L2 есть CRC, во-вторых, вышележащие протоколы (TCP) тоже будут обеспечивать целостность доставки. В итоге из заголовка выбросили лишние поля, стало проще, быстрее и надежнее.

Aвтоконфигурирование и служебные протоколы


Существует два основных варианта назначения IPv6-адресов: stateless autoconfiguration — это когда роутер отправляет клиентам адрес сети, шлюза по умолчанию и прочую необходимую информацию и statefull autoconfiguration — когда используется DHCPv6-сервер. Поэтому если раньше DHCP был единственным вариантом раздачи информации, то в IPv6 он стал дополнительным.

ICMP 6-й версии тоже не остался без внимания, в него было добавлено множество фич. Например, механизм Router discovery — клиенты могут слушать, что сообщает им роутер (сообщения ICMPv6 тип 134 router advertisement, которые приходят в рамках процесса stateless autoconfiguration), и при включении могут сразу звать роутер на помощь, мол, помоги сконфигуриться (сообщения ICMPv6 тип 133 router solicitation).

Еще добавили механизм Neighbor discovery — можно сказать, что это своеобразная замена ARP, которая помогает находить мак-адреса соседей, маршрутизаторы и даже обнаруживать дублирующиеся адреса в сегменте (duplicate address detection DaD), работает исключительно по мультикасту. Чистого бродкаста в IPv6 уже нет, но не нужно забывать, что глупые копеечные свичи весь мультикаст рассылают широковещательно, в итоге часть новых механизмов сводится на нет.

Инструментарий пентестера IPv6


Перед тем как перейти к уязвимостям и атакам, неплохо бы рассмотреть, какие есть инструменты в арсенале пентестера. До недавнего времени существовал только один набор утилит для проведения атак на протоколы IPv6 и ICMPv6. Это был THC-IPV6 от небезызвестного Марка ван Хаузера, того самого автора брутфорсера THC-hydra и массы других незаменимых инструментов. Именно он в 2005 году серьезно заинтересовался этой темой и вплотную занялся ресерчем протокола IPv6. И до недавнего времени оставался первопроходцем.

Но в последний год ситуация начала меняться. Все больше исследователей обращают свое внимание на IPv6, и, соответственно, стали появляться новые утилиты и новые сканеры. Но на сегодня THC-IPV6 по-прежнему остается лучшим набором утилит для пентестера. В его комплект входит уже более 60 инструментов, разделенных на различные категории — от сканирования и митмов до флудинга и фаззинга. Но не будем забывать и тру инструмент scapy — утилиту, которая позволяет вручную создавать любые пакеты, с любыми заголовками, даже если такие вариации не предусмотрены ни в одном RFC.

Разведка в IPv6-сетях


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

К счастью, выход есть. Вначале нужно будет найти AS (автономную систему), которая принадлежит цели (объекту пентеста). Сервисов, позволяющих искать по AS их владельцев, вполне достаточно, можно это делать прямо на сайтах региональных регистраторов (европейский регистратор — это RIPE NCC). Затем, зная номер AS, принадлежащей конкретной компании, можно уже искать выделенные ей IPv6-подсети.

Самый удобный такой поисковый сервис предоставляет Hurricane Electric (bgp.he.net). В итоге можно найти несколько огромных подсетей, которые, как мы уже убедились, нереально просканировать на предмет живых хостов. Поэтому нужно составлять список часто используемых адресов и проводить сканирование уже точечно по ним.

Каким образом можно собрать такой словарь? Если проанализировать, как в компаниях, которые уже внедрили IPv6, назначаются адреса клиентам, то можно выделить три основные группы: автоконфигурация, ручное назначение адресов и DHCPv6.

Автоконфигурация может осуществляться тремя способами: на основе мак-адреса, с использованием privacy option (то есть рандомно и, например, меняться раз в неделю) и fixed random (полностью случайным образом). В данной ситуации возможно сканировать только те адреса, что строятся на основе мака. В результате могут выйти подсети, сравнимые по размеру с IPv4 класса А, процесс работы с такими сетями не очень быстрый, но все равно это уже вполне реально. Например, зная, что в целевой компании массово используются ноутбуки определенного вендора, можно строить сканирование, основываясь на знаниях о том, как будет формироваться адрес.

Если адреса задаются вручную, то они могут назначаться либо случайным образом, либо по некому шаблону. Второе, естественно, в жизни встречается гораздо чаще. А паттерн может быть ::1,::2,::3 или ::1001,::1002,::1003. Также иногда в качества адреса используются порты сервисов, в зависимости от сервера: например, веб-сервер может иметь адрес ::2:80.

Если же брать DHCPv6, то в этом случае обычно адреса раздаются последовательно из пула (точно такое же поведение можно наблюдать и с обычным DHCPv4-сервером). Зачастую в DHCPv6 можно встретить пул вроде ::1000-2000 или ::100-200. Поэтому в итоге берем утилиту alive6 (она включена в комплект THC-IPV6 и, как и все рассматриваемые сегодня инструменты, по дефолту входит в Kali Linux) и запускаем:

# alive6 -p eth0 2001:67c:238::0-ffff::0-2
  Alive: 2001:db8:238:1::2 [ICMP echo-reply]
  Alive: 2001:db8:238:3::1 [ICMP echo-reply]
  Alive: 2001:db8:238:3::2 [ICMP echo-reply]
  Alive: 2001:db8:238:300::1 [ICMP echo-reply]
  Scanned 65536 systems in 29 seconds and found 4 
  systems alive


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

Но это еще не все — естественно, можно использовать и DNS. С приходом IPv6 никуда не делись трансферы DNS-зоны и брутфорсы DNS по словарю. Применив все эти техники вместе, можно обнаруживать до 80% всех включенных хостов в заданной IPv6-подсети, что очень неплохо. В случае же компрометации одного лишь хоста обнаружить всех его соседей не составит никакого труда при помощи мультикаста. Достаточно будет запустить ту же утилиту alive6, только уже с ключом -l.

Из свежих фич THC-IPV6, и в частности утилиты alive6, можно отметить возможность искать живые хосты, передавая в качестве паттерна для перебора целую IPv4-подсеть:

# alive6 -4 192.168.0/24


Если же брать классическое сканирование, то здесь практически ничего не изменилось. Тот же Nmap, те же варианты сканирования портов, единственное отличие в том, что теперь сканировать можно только один хост за раз, но это вполне очевидное решение.

Пожалуй, единственная дополнительная техника при сканировании портов — это сканирование IPv4 вначале, а затем получение IPv6-информации по этим хостам. То есть некое расширение поверхности атаки. Для этого можно использовать как вспомогательный модуль метасплойта ipv6_neighbor, так и отдельные скрипты ipv6_surface_analyzer. Работают они по схожему принципу — принимают на входе IPv4-подсеть, сканируют ее, находят живые хосты, проверяют порты на открытость, а затем, определив MAC-адрес, высчитывают по нему IPv6-адрес и уже пробуют работать по нему. Иногда это действительно помогает, но в некоторых случаях (privacy option) IPv6-адреса обнаружить не удается, даже несмотря на то, что они есть.

INFO


При использовании протокола IPv4 и ARP достаточно полезно было иногда смотреть ARP-кеш; что на линуксе, что на Windows-платформе это можно было сделать, используя команду arp -a.
Теперь же, в случае IPv6, в линуксе, чтобы посмотреть соседей, используется команда ip -6 neighbor show, а в Windows среде это можно сделать командой netsh interface ipv6 show neighbors.


Угрозы периметра IPv6



Если рассмотреть внешний периметр, то можно обнаружить, что многие компании, которые уже начали внедрять IPv6, не спешат закрывать свои административные порты (SSH, RDP, Telnet, VNC и так далее). И если IPv4 уже почти все стараются как-то фильтровать, то про IPv6 или забывают, или не знают, что их нужно защищать так же, как и в случае с IPv4. И если можно отчасти понять используемый IPv4 телнет — например, ограниченная память или CPU не позволяют в полной мере использовать SSH, — то каждое устройство, которое поддерживает сегодня IPv6, просто гарантированно будет поддерживать и протокол SSH. Бывают даже случаи, когда ISP выставляют в мир административные порты IPv6 на своих роутерах. Выходит, что даже провайдеры более уязвимы к IPv6-атакам. Происходит это по различным причинам. Во-первых, хороших IPv6-файрволов еще не так много, во-вторых, их еще нужно купить и настроить. Ну и самая главная причина — многие даже и не подозревают об угрозах IPv6. Также бытует мнение, что пока нет IPv6-хакеров, малвари и IPv6-атак, то и защищаться вроде как не от чего.

Угрозы, поджидающие внутри LAN


Если вспомнить IPv4, то там обнаружится три атаки, которые эффективны и по сей день в локальных сетях, — это ARP spoofing, DHCP spoofing, а также ICMP-редиректы (подробно этот класс атак освещался во время моего выступления на PHDays, так что можешь поискать соответствующее видео в Сети).

В случае же протокола IPv6, когда атакующий находится в одном локальном сегменте с жертвой, ситуация, как ни странно, остается примерно такой же. Вместо ARP появился NDP, на смену DHCP пришла автоконфигурация, а ICMP просто обновился до ICMPv6. Важно то, что концепция атак осталась практически без изменений. Но кроме того, добавились новые механизмы вроде DAD, и, соответственно, сразу же появились новые векторы и новые атаки.

Протокол обнаружения соседей (Neighbor Discovery Protocol, NDP) — это протокол, с помощью которого IPv6-хосты могут обнаружить друг друга, определить адрес канального уровня другого хоста (вместо ARP, который использовался в IPv4), обнаружить маршрутизаторы и так далее. Чтобы этот механизм работал, а работает он с использованием мультикаста, каждый раз, когда назначается линк-локал или глобал IPv6-адрес на интерфейс, хост присоединяется к мультикаст-группе. Собственно, используется всего два типа сообщений в процессе neighbor discovery: запрос информации, или NS (neighbor solicitation), и предоставление информации — NA (neighbor advertisement).
Взаимодействие в таком режиме можно увидеть на рис. 3.


Рис. 3. Штатная работа ND

В результате атакующему нужно всего лишь запустить утилиту parasite6, которая будет отвечать на все NS, пролетающие в отдельно взятом сегменте (см. рис. 4). Перед этим нужно не забыть включить форвардинг (echo 1 > /proc/sys/net/ipv6/conf/all/forwarding), в противном случае произойдет не MITM-атака, а DoS.


Рис. 4. Работа утилиты parasite6

Минусами такой атаки является то, что атакующий будет пытаться отравить ND-кеш всех хостов, что, во-первых, шумно, во-вторых, затруднительно в случае больших объемов трафика. Поэтому можно взять scapy и провести эту атаку вручную и прицельно. Сначала необходимо заполнить все необходимые переменные.

>>> ether=Ether(src="00:00:77:77:77:77",
dst="00:0c:29:0e:af:c7")
Вначале идут адреса канального уровня, в качестве адреса отправителя выступает мак-адрес атакующего, в качестве адреса получателя — мак-адрес жертвы.
>>> ipv6=IPv6(src="fe80::20d:edff:fe00:1",
dst="fe80::fdc7:6725:5b28:e293")
Далее задаются адреса сетевого уровня, адрес отправителя спуфится (на самом деле это адрес роутера), адрес получателя — это IPv6-адрес жертвы.
>>> na=ICMPv6ND_NA(tgt="fe80::20d:edff:
fe00:1", R=0, S=0, O=1)


Третьей переменной нужно указать правильно собранный пакет NA, где ICMPv6ND_NA — это ICMPv6 Neighbor Discovery — Neighbor Advertisement, а tgt — это собственно адрес роутера, который анонсируется как адрес атакующего. Важно правильно установить все флаги: R=1 означает, что отправитель является роутером, S=1 скажет о том, что анонс отправляется в ответ на NS-сообщение, ну а O=1 — это так называемый override-флаг.

>>> lla=ICMPv6NDOptDstLLAddr
(lladdr="00:00:77:77:77:77")
Следующая переменная — это Link local адрес ICMPv6NDOptDstLLAddr (ICMPv6 Neighbor Discovery Option — Destination Link-Layer). Это мак-адрес атакующего.
>>> packet=ether/ipv6/na/lla
Осталось собрать пакет в единое целое, и можно отправлять такой пакет в сеть.
>>> sendp(packet,loop=1,inter=3)


Значение loop=1 говорит о том, что отправлять нужно бесконечно, через каждые три секунды.
В итоге через некоторое время жертва обновит свой кеш соседей и будет отправлять весь трафик, который предназначается маршрутизатору, прямо в руки атакующему. Нужно отметить, что для того, чтобы создать полноценный MITM, потребуется запустить еще один экземпляр scapy, где адреса будут инвертированы для отравления роутера. Как видишь, ничего сложного.

Также стоит отметить, что в IPv6 не существует понятия gratuitous NA, как это было во времена ARP (gratuitous ARP — это ARP-ответ, присланный без запроса). Но вместе с тем кеш ND живет недолго и быстро устаревает. Это было разработано, чтобы избегать отправки пакетов на несуществующие MAC-адреса. Поэтому в сети IPv6 обмен сообщениями NS — NA происходит очень часто, что сильно играет на руку атакующему.

Угрозы конечных хостов


И раз уж заговорили про RA, то плавно перейдем к угрозам конечных хостов, и в частности к тем хостам, работа которых с IPv6 не планировалась. То есть рассмотрим атаку на хосты, работающие в дефолтной конфигурации IPv6, в обычной IPv4-сети. Что произойдет, если любая современная ОС получит пакет RA? Так как любая система сейчас поддерживает IPv6 и ожидает такие пакеты, то она сразу превратится в так называемый дуал стек. Это ситуация, когда в пределах одной ОС используется и IPv4, и IPv6 одновременно. При этом сразу же откроется целый ряд ранее недоступных векторов. Например, можно будет сканировать цель, ведь IPv4 обычно фильтруется, а про IPv6, как уже знаем, зачастую вообще не думают.

Кроме того, в большинстве ОС IPv6 имеет приоритет над IPv4. Если, например, придет запрос DNS, то большая вероятность, что IPv6 сработает раньше. Это открывает огромный простор для различных MITM-атак. Для проведения одной из самых эффективных потребуется разместить свой зловредный IPv6-маршрутизатор. Каждый маршрутизатор IPv6 должен присоединиться к специальной мультикаст-группе. Это FF02::2. Как только роутер присоединится к такой мультикаст-группе, он сразу же начинает рассылать сообщения — RA. Сisco-роутеры рассылают их каждые 200 с по дефолту. Еще один нюанс состоит в том, что клиентам не нужно ждать 200 с, они отправляют RS-сообщение — Router Solicitation — на этот мультикаст-адрес и таким образом незамедлительно требуют всю информацию. Весь этот механизм называется SLAAC — Stateless Address Autoconfiguration. И соответственно была разработана атака на него с очевидным названием SLAAC attack.

Атака заключается в том, что нужно установить свой роутер (не стоит понимать буквально, в роли роутера может выступать любой линукс или даже виртуальная машина), который будет рассылать сообщения RA, но это только полдела. Также атакующему потребуется запустить DHCPv6-сервер, DNSv6 и NAT64-транслятор. В качестве сервиса, способного рассылать сообщения RA, можно использовать Router Advertisement Daemon (radvd), это опенсорсная реализация IPv6-роутера. В итоге после правильной конфигурации всех демонов жертва получит RA и превратится в дуал стек и весь трафик жертвы будет абсолютно незаметно идти через IPv6.

На маршрутизаторе атакующего этот трафик будет перебиваться натом в обычный IPv4 и затем уже уходить на настоящий роутер. DNSv6-запросы также будут иметь приоритет и также будут обрабатываться на стороне атакующего.

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

Как же защищать IPv6


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


Рис. 5. Схема SLAAC attack


Рис. 6. Результат SLAAC attack

Отдельно существует защита от ложных RA-сообщений, которые, как известно, должны приходить только от маршрутизаторов. Компания Cisco реализовала фичу под названием Router Advertisement Guard, которая предотвращает инжект недоверенных RA-сообщений, отдельно помечая потенциально небезопасные порты. То есть пакеты RA просто не будут приниматься с пользовательских портов. Работает эта фича по аналогии с DHCP-снупингом. Единственный минус в том, что доступна такая фича только на определенном классе железок — на каталистах серий 2960S, 3560 и 3750. Кроме того, в 2012 году появились DHCPv6 Guard и NDP Snooping, опять же это аналоги DHCP Snooping и Dynamic ARP Inspection из мира IPv4. Доступны эти защитные механизмы на каталистах 4500/4948 и на роутерах серии 7600.

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

netsh int ipv6 set int X routerdiscovery=disabled


где X — это индекс интерфейса (просмотреть индексы IPv6-интерфейсов можно командой netsh int ipv6 show int). Проверяется результат командой netsh int ipv6 show int X.

Если же рассмотреть ситуацию с обнаружением атак IPv6, то в целом там все хорошо. Детектить IPv6-атаки достаточно легко, но пока их сложно превентить.

Завершаем рассказ


Что же имеем в сухом остатке? Как оказалось, сам по себе протокол IPv6 не безопаснее, но при этом и не дырявее, чем IPv4. Проблема лежит в недостаточных знаниях и опыте работы с этим протоколом. Нужно фильтровать IPv6 на периметре и выключать его, если он не используется на конечных устройствах. Многие люди считают, что IPv6 значительно безопаснее, чем IPv4, потому, что IPv6 требует использования IPsec. Но это миф. Да, IPsec может сразу работать в среде IPv6, но ни разу не является обязательным. IPv6 делает некоторые вещи лучше, другие — хуже, но большинство вещей просто отличаются от того, к чему все успели привыкнуть. Другими словами, протокол IPv6 не более или менее безопасен, чем IPv4, протокол IPv6 просто уникален и несет свои собственные соображения на счет безопасности.

Автор: Александр Дмитриенко, PentestIT



Впервые опубликовано в журнале «Хакер» от 11/2014.

Подпишись на «Хакер»




Автор: @XakepRU

Комментарии (41)

  • +8
    Соответственно, адресов доступно 2^128. Это примерно по 100 адресов каждому атому на поверхности Земли.

    Реальная цифра на много-много порядков ниже. Еще долго не будет подсетей на все 2^64 хостов…
    Резко упростили задачу маршрутизаторам, ведь уже не надо пересчитывать контрольные суммы, и в итоге IPv6 обрабатывается быстрее, чем IPv4.

    А на самом деле ничего особо и не изменилось. Расчет чексумм даже на конечных хостах обычно делают аппаратно, силами сетевухи. На нормальных железных маршрутизаторах, где нужна высокая скорость, весь цикл обработки и передачи пакета выполняется за детерминированное время и без задействования ЦП общего назначения.
    И если можно отчасти понять используемый IPv4 телнет — например, ограниченная память или CPU не позволяют в полной мере использовать SSH

    Ну не бывает такого в XXI веке.
    Реальная причина:
    1) Раньше для того, чтобы с железкой можно было работать по ssh, ей была нужна лицензия К9 (сложности с закупкой, согласования ФСБ и т.д.). Без нее только нешифрованные протоколы. Сейчас таких ограничений обычно уже нет.
    2) Windows например из коробки не имеет ssh, но имеет telnet. Возможно, для кого-то это будет аргументом.
    Во-первых, хороших IPv6-файрволов еще не так много, во-вторых, их еще нужно купить и настроить

    Да тут и файрвол не нужен. Простой пакетный фильтр есть везде.
    Единственный минус в том, что доступна такая фича только на определенном классе железок

    Это если надо фильтровать RA.
    В случае, если IPv6 в организации не используется, правильнее просто повесить на все аксессные порты коммутаторов ipv6 acl с «deny any any», это есть примерно везде. Всё, трафик IPv6 между различными конечными железками не пройдет. Желательно делать то же и на виртуальных свитчах гипервизоров. И вместе с этим отключать IPv6 на конечных системах, конечно. Но очень легко забыть это сделать, потому прикрывать хосты со стороны сети надо.
    IPv6 делает некоторые вещи лучше, другие — хуже, но большинство вещей просто отличаются от того, к чему все успели привыкнуть.

    Я бы сказал, что он делает всё в общем и целом приблизительно так же. Основное изменение — адресное пространство шире. Остальные изменения на бумаге выглядят круто (Никакого броадкаста, только мультикаст! Никаких лишних чексумм, экономия ресурсов! Встроенная поддержка IPSec — безопасность!), но по факту вообще ни черта не меняют..
  • +4
    Титанический материал, не для пятницы. В избранное однозначно!

    Спасибо команде «Хакера», для такого хомяка как я очень интересно.
  • 0
    Вообще IPv6 выглядит немного странно. Я раньше не вдаваясь в подробности думал, что там реально 2^128 адресов. Реально /64 подсети выдают всем подряд, а многие провайдеры, например, раздают /48 подсети на простые VPS-ки. Т.е. реально адресов в сравнение с IPv4 больше в 32000 раз. Это неплохо, но экспоненциального роста не выдержит. Хотя на ближайшие десятки лет видимо хватит.
    • +2
      Это вам так кажется, потому что вы раннюю эпоху IPv4 не застали. В частности то, что вы сейчас наблюдаете — это повторение эпохи классовой адресации на новом витке спирали. Если сетей будет не хватать — перейдут к аналогу CIDR, делов-то.
  • +2
    Когда читаю фразы «Такой адрес всегда начинается с FE80, ну а последние 64 бита — это мак-адрес с FFFE, вставленными посередине, плюс один бит инвертируется», невольно задумываюсь — то ли я неманьяк, то ли авторы спецификации — маньяки.

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

    Правда — за что такие извращения? Я еще понимаю, будь там «Такой адрес всегда начинается с FE80, ну а последние 64 бита — это мак-адрес», но зачем «посередине» что-то вставлять (и что значит середина), и зачем бит инвертировать?!
    • 0
      Это было сделано для того чтобы исключить возможность дубликатов таких адресов.
      Затем уже стали добавлять различные секьюрити фичи, и количество таких адресов на интерфейсе стало расти.
      • +1
        Но ведь очевидно, что, если мы делаем из MAC-а что-то производное по статическим правилам, то при совпадении MAC-ов мы получим и совпадающие производные данные?

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

        А тут — «мы берем MAC, переставляем четные байты с нечетными, инвертируем 13 бит в безлунную ночь — и на выходе для одинаковых MAC-ов получаем одинаковые текстовые строки, караул, враги!»
        • 0
          На самом деле, поработав месяц — два со средней IPv6 сетью, уже начинаешь ориентироваться по адресам и они не вызывают такого отторжения, как в начале.
          И разобраться получается без особых проблем.
          Но протокол конечно же многократно допиливался и по прежнему далек от идеального.
          • 0
            Просто он вызывет стойкое чувство, будто его делал Microsoft после того, как какой-нибудь IPv4 сделал Apple. Просто в каждой строчке сквозит «мы сделали то же, но точно наоборот, чем у них!»

            А если серьезно, то вот таких сложностей на ровном месте там столько, что невольно задумываешь, не они ли причина того, что протокол приходится насаждать в юзерах (как картошку на Руси), а не отдавать в радостные руки желающих что-то новое попробовать.

            Грубо: даже если провайдер сделал IPv6, то вариантов, как он работает — масса, способов дружбы с IPv4 — масса, но по факту запуск сего чуда техники для любого желающего клиента провайдера превращается в рулетку. Сайтам тем же поддержка IPv6 тоже не дается легко, и комбинаций технологий IPv6, софта на серверах и у клиентов, всевозможных ошибок настройки и реализации — их столько, что проще не настраивать.
            • 0
              Согласен с тем, что определенные трудности IPv6 с собой приносит.
              Но ситуация состоит в том, что переход на него неизбежен и этот переход уже идет полным ходом.
              Если брать обычного клиента, то в случае нативного получения IPv6 от оператора проблем обычно не возникает.
              Всё происходит прозрачно, так же как в IPv4, прилетит вся нужная информация и в большинстве случаев всё будет жужжать.
              Если коснуться ситуации с различными IPv6 туннелями, то по статистике мирового IPv6 трафика они уже своё отжили, доля ничтожная, преобладает уже чистый IPv6.
              • –1
                Руки повырывать за всякие teredo и прочее счастье,
                а что касается «само прилетит», то таки нет. Вам прислать скриншот какого-нибудь Длинка, его раздела про настройку IPv6? Это не одну бутылку надо выкурить и не один кальян выпить, чтобы понять, что ушлые китайцы имели в виду! Техподдержка провайдеров, ведая, что не всякий роутер хорошо и по стандарту работает с IPv6, обычно говорит, что «мы протестировать 8 моделей, которые нашли в продаже, вот их и покупайте, а 9-я и далее — х.з. как работает», и ведь они правы! И при этом глюки роутеров меняются от версий прошивки.

                Но, повторюсь, протокол на взгляд новичков сделан неудобным и усложненным для понимания, на него долго переходили (сколько уже говорят про него?), но переход, увы, неизбежен, поскольку еще одно изобретение протокола просто уж очень тяжко будет. О том, что масса людей и компаний просто не обладают IPv6-enable устройствами — это вообще тема плача Ярославны всех провайдеров. О том, что кроме железа есть еще и биллинги и прочее ПО, тоже помолчим.

                P.S. Я уже не говорю, какая «прелесть» найти провайдера, которые готов по BGP с IPv6 через туннель подключать. Приходится туннели через полмира тянуть: в he.net да вот (спасибо!) в МТУ дают, и это очень хорошо.

                В общем
            • +1
              Грубо: даже если провайдер сделал IPv6, то вариантов, как он работает — масса
              Ой, а IPv4 прямо не так. IPoE /30, IPoE PPP Unnumbered /24, всякие PPPoE, PPTP.

              Сайтам тем же поддержка IPv6 тоже не дается легко, и комбинаций технологий IPv6, софта на серверах и у клиентов, всевозможных ошибок настройки и реализации — их столько, что проще не настраивать.
              Э? Ну фиг знает, я использую IPv6 уже чуть ли не 5 лет везде где можно, и никаких особых трудностей не испытывал и не испытываю.
        • 0
          А тут — «мы берем MAC, переставляем четные байты с нечетными, инвертируем 13 бит в безлунную ночь — и на выходе для одинаковых MAC-ов получаем одинаковые текстовые строки, караул, враги!»
          Если у вас карточки с одинаковыми MAC-адресами в одной сети, то ничего и не должно было работать. Правила были придуманы, чтобы уникальные адреса, порождённые из MAC'а не пересеклись с уникальными адресами, порождёнными другими способами, как я уже писал.
    • +4
      Про причины всех этих извращений с инвертированием битов, FFFE и т.д. отлично расписано здесь: sites.google.com/site/yartikhiy/home/ipv6book
      И даже на русском языке.
      • 0
        Большое спасибо за документ!
    • +3
      Правда — за что такие извращения?
      Чтобы поддерживать не только MAC-адреса, но и полноценный EUI-64. В который MAC-адрес превращается вот таким вот способом.

      Я еще понимаю, будь там «Такой адрес всегда начинается с FE80, ну а последние 64 бита — это мак-адрес», но зачем «посередине» что-то вставлять (и что значит середина),
      Середина — это ровно середина. А технически — это старшие 16 бит дополнительно идентификатора (я надеюсь вы знаете что и в MACе и в EUI-64 первые 24 бита — это номер, выданный организации, а последние биты — организация решает как использовать внутри себя сама). Однако свобода у организации ограничена: старшие два байта не могут равны FFFF (используется для превращения EUI-48 в EUI-64) или FFFE (используется для превращения EUI-48 в MAC). Что запрещены самые старшие номера — логично? По моему — вполне.

      и зачем бит инвертировать?!
      А тут всё ещё проще: чтобы 0 стал 1, а 1 стала 0. Я не шучу. Дело в том, что в MAC-адресе есть поле, которое показывает — у нас глобально-уникальный адрес или локально управляемый (==выбираемый администратором). Если бит не инвертировать, то все выбираемые руками IPv6 адреса приходилось бы вводить с кучей нулей, для того, чтобы задать единичку в этом поле (которое будет находиться аккурат-таки посреди уже IPv6 адреса). Но поскольку бит инвертирован, то для «руками выбираемых адресов» можно использовать краткую запись с "::" — что удобно.

      В общем эта. Вы в какой-то мере правы. Это действительно то, чем славится Microsoft — обратной совместимостью. То, что я нас в конторе проходит под названием «всюду лошади» из-за известной байки.Не уверен, что Apple подход «выкиньте нафиг всю ADB-периферию, мы переходим на USB!» был бы встречен с бо́льшей радостью.
  • 0
    стояли задачи сделать более быстрый протокол и с большим количеством адресов, а не более безопасный и защищенный


    Неправда, одной из встроенных в протокол фич является, например, IPsec. Так что за безопасность разроботчики тоже думали.
    • 0
      Опишите, что изменилось по сравнению с IPv4 с точки зрения IPSec.
      • 0
        Специально же выделил: он стал частью протокола.
        • +1
          А конкретнее? Что изменилось-то? Я не понимаю, что значит «стал частью протокола». Вот есть IKE. Есть ESP инкапсуляция. Они стали частью IPv6? А поверх IPv4 они, значит, не работали?
          • 0
            «Cтал частью протокола» значит вендоры, которые под ipv6 девайсы разрабатывают должны реализовывать поддержку IPsec.
            • +1
              И чо? Везде, где он нужен, он и раньше был. Вон виндовая инфраструктура например умела это делать (довольно автоматически шифровать общение в пределах домена между хостами) как минимум во времена 2003, правда — никто этим не пользовался. Что изменилось-то? Опять же, клиентская часть давно реализована на всех возможных платформах.

              Да и вообще, не могу сказать чтобы я сильно его любил. Сложный он. Много чего может пойти не так. Но вариантов нет.
              • 0
                Складывается впечатление, что не понимаем друг друга. Я-то про то, что создатели протокола заморочились и на безопасности протокола (вопреки тому, о чём говорится в цитате), а не только на количестве адресов и скорости. Поэтому и добавили IPsec в сам протокол.

                А на счёт сложности и прочего и прочего, если вы не провайдер, то для вас вряд ли что-то поминяется. Вам ваш пров даст ип вы его в настройки wan пропишите и всё. Внутри сетки вольны использовать ipv4. Думаю, на внутреннюю сетку ип адресов хватит.
                • –2
                  Поэтому и добавили IPsec в сам протокол.

                  Так я и говорю, что ничего не изменилось — в IPv4 он тоже был :) Серьезно — вы зациклились на паверпоинтовских презентациях. Подумайте с практической точки зрения. С этим изменением станет лучше жить? Нет, так как на практике не меняется ничего. Ну ок, стандартизировали нечто, что и так было у всех уже как лет 10-20. Офигеть, я счастлив.

                  А, нет, погодите, у нас в стране сильная криптография вообще на каком-то полулегальном положении в большинстве случаев.
                  а не только на количестве адресов и скорости

                  Так выигрыша в скорости тоже нет. За счет выросших заголовков будет скорее проигрыш даже. Больше пакетов на тот же объем данных. Вроде еще какие-то сложности были с v6 заголовками, но из головы вылетело.
                  А на счёт сложности и прочего и прочего, если вы не провайдер, то для вас вряд ли что-то поминяется.

                  Конечно. Я буду продолжать настраивать IPSec для IPv6 в точности как я это делаю сейчас для IPv4. Провайдеру проще, ему IPSec вообще не нужен.
                  Вам ваш пров даст ип вы его в настройки wan пропишите и всё.

                  Но конечно же такое если и будет, то только на самых первых порах и у самых некомпетентных провайдеров.
                  Внутри сетки вольны использовать ipv4. Думаю, на внутреннюю сетку ип адресов хватит.

                  Тут, уж простите, глупость сказана.
                  1) IPv4 не маршрутизируется по IPv6 сети без туннелирования. Нельзя просто так иметь снаружи v6 адрес и внутри v4 сеть. Транслировать адреса можно, но это — жуткий, отвратительный костыль.
                  2) Если бы внутренние сети по миру использовали глобально маршрутизируемые v4 адреса, они закончились бы еще лет 15 назад. Слава NAT, великому костылю, отодвинувшему глобальную задницу на какое-то время.
                  3) Провайдер может выдать клиенту не только адрес на внешний интерфейс, но и глобально маршрутизируемую внутреннюю сеть для назначения устройствам за роутером, причем всё это автоматически. Это — прикольное изменение. Но для хомячков снова ничего особо не изменится (была 192.168.0.0/24 с NAT, где тоже обычно никто ничего руками не менял, станет другая с незапоминаемыми адресами и без NAT), а корпоративные пользователи все равно сами будут нарезать блоки.
                  • +2
                    Ваш разговор похож немного на разговор глухого со слепым. Вы оба по своему правы.

                    С одной стороны. Разработчики IPv6 несомненно думали и о безопасности тоже — отсюда IPsec и многие другие фишки.

                    С другой стороны. Полезные вещи, которые не требуют наличия 128-битных адресов никто не запрещал «вынуть» из обоймы протоколов, разрабатывавшихся вместе с IPv6 и реализовать поверх IPv4. Что и было проделано, в частности, с IPsec'ом.

                    Разумеется в результате в момент перехода с IPv4 на IPv6 вы получаете, по большому счёту, только новые «большие» 128-битные адреса и некоторое количество плюшек, прямо опирающихся на то, что адреса — таки 128-битные.

                    Всё остальное уже было внедрено раньше.

                    Вот и всё. О чём тут спорить-то?
                    • 0
                      да
                    • 0
                      Что и было проделано, в частности, с IPsec'ом.

                      А откуда уверенность, что IPSec изначально разрабатывался под IPv6 и лишь потом был перенесен на IPv4? Что-то я не вижу такого в RFC2401…
                      • –1
                        А думать вас мама в детстве не учила? Конечно решение о том, что IPsec будет поддерживать не только IPv6, но и IPv4 было принято до полного окончания работы над IPsec'ом-для-IPv6, но они разрабатывались совместно, что как бы совершенно очевидно: как иначе мог в IPsec'овском RFC 2401, выпущенном в ноябре 1998 оказаться раздел, посвящённый IPv6, который получил свой RFC 2046 только в декабре 1998го? И в соответствующих исторических обзорах эта информация ест. Если не верите — можно поговорить с людьми, которые это всё разрабатывали, благо они, в большинстве своём, ещё живы.
                        • 0
                          но они разрабатывались совместно

                          Смотрим выше:
                          «никто не запрещал «вынуть» из обоймы протоколов, разрабатывавшихся вместе с IPv6 и реализовать поверх IPv4. Что и было проделано, в частности, с IPsec'ом.»
                          Вы уж определитесь, что там было — «одновременно» или «вынули и позже добавили в другой»…
                          как иначе мог в IPsec'овском RFC 2401, выпущенном в ноябре 1998 оказаться раздел, посвящённый IPv6, который получил свой RFC 2046 только в декабре 1998го?

                          Открою страшную тайну.
                          Даже две.

                          1) Над IPSec и IPv6 работали разные working group'ы.
                          2) Работа IETF над стандартизацией нового протокола обычно занимает годы, и проходит совершенно открыто. Например, прямо сейчас таких групп, наверное, под сотню наберется. Вы легко можете вступить в любую из них (бесплатно, без СМС и с самой базовой регистрацией) и поучаствовать в создании протокола, который через несколько начнет свое победоносное шествие по миру, когда его стандарт финализируют :) И из этого следует, что все знают, чем занимаются соседи, и по многим технологиям работа ведется параллельно в нескольких различных группах.

                          А с IPSec было довольно просто. Возникла потребность «здесь и сейчас». Создали протокол. Приблизительно все созданные в то время протоколы, которым есть дело до L3, разрабатывались с учетом IPv6 одновременно с IPv4.
                  • 0
                    Вы упорно отказываетесь меня понимать. Мой-то посыл прост (в сотый раз): разработчики думали и о безопасности протокола, в приведённой цитате это отрицается. То, что делается поверх, это уже тараканы каждого отдельного индивида. Тем более как там у вас IPSec через NAT работал, нормально?

                    Так выигрыша в скорости тоже нет.


                    jumbo пакеты?

                    Нельзя просто так иметь снаружи v6 адрес и внутри v4 сеть.


                    Прям смешно читать, особенно зная, что чёрная коробочка под столом так и настроена.
                    • –2
                      Мой-то посыл прост (в сотый раз): разработчики думали и о безопасности протокола, в приведённой цитате это отрицается.

                      Цитата:
                      «стояли задачи сделать более быстрый протокол и с большим количеством адресов, а не более безопасный и защищенный»

                      IPv6 стал более защищенным? Нет. Так что по этому пункту та цитата полностью верна. Неверна она по пункту «более быстрый».

                      Когда думают — что-то меняется. Но мы видим, что у IPv6 те же фичи и векторы атак, что и у IPv4.
                      jumbo пакеты?

                      А для IPv4 так сделать нельзя? Да и сложно пропустить пакет размером более 1500 байт через интернет…
                      Прям смешно читать, особенно зная, что чёрная коробочка под столом так и настроена.

                      На NAT46? А зачем?
                      • 0
                        Неверна она по пункту «более быстрый».

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

                        разработчики думали и о безопасности протокола

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

                        Основной посыл, который я пробовал передать в этой статье, это то, что IPv6 уже пришел, его уже нужно знать и в том числе быть готовым к новым угрозам, которые он в себе несет.
                        • 0
                          О безопасности тогда не думали, в те времена всё было плейн текстом.
                          Это вы так перевели фразу Network security was a design requirement of the IPv6 architecture, and included the original specification of IPsec? Мне казалось, что она как-то по другому переводится.

                          IPsec не является каким-либо обязательным к использованию элементом в IPv6.
                          Не стоит мешать мухи с котлетами. IPsec являлся обязательным к использованию элементом как оно и разрабатывалось: в соответствующем разделе так просто и написано: The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401].

                          То, что после этого выяснилось, что всякие разные спецслужбы не допустят реализации IPv6 прямо в таком виде и потребовали сделать IPsec опциональным не означает, что «о безопасности тогда не думали», уж извините. Тем не менее и даже и сейчас в соответствующем RFC написано: Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301]a SHOULD for all IPv6 nodes. Ну и всякие разные «buzzwords» объясняющие почему нужно MUST заменять на SHOULD.

                          Основной посыл, который я пробовал передать в этой статье, это то, что IPv6 уже пришел, его уже нужно знать и в том числе быть готовым к новым угрозам, которые он в себе несет.
                          Посыл хорош, но это не отменяет того факта, что в статье написана ложь, уж извините.
                    • 0
                      Тем более как там у вас IPSec через NAT работал, нормально?

                      Пропустил…

                      Если за NAT работает одна сторона, то проблем обычно нет.
  • +1
    Поправка, RIR'ам адреса были розданы уже фиг знает когда. Европа живёт в /8 — это следующий этап depletion. Сейчас плавно заканчиваются адреса у LIR'ов, которые хапали как не в себя в момент когда можно было, плюс идёт консолидация и подъедание sparse-диапазонов. Я знаю как минимум три сделки по покупке бизнеса, при котором бизнес покупался только за IP'шники.

    Когда этот ресурс будет подъеден, наступит очередь локальной оптизимизации у конечных потребителей (не особо длинный). После этого начнётся настоящий дефицит с отказами по причине «нет свободных адресов».

    По поводу «новый блок будет выдан». Не будет выдан. Всё. LIR может претендовать на /22 (я путаюсь — то ли /23, то ли /21), и больше никак и ни при каких условиях. Это называется last /8, и он уже года два.

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

    По моим наблюдениям в перспективе пары лет адреса в нычках ещё есть.
    • +2
      Беларусь уже больше года, если не два сидит за NAT-ом. Это очень больно и неприятно, например, более половины суток забанен в гугле. Так что скорей бы уже эти «нычки» закончились и IPv6 пошло во все поля.
      • 0
        А туннель наружу и оттуда хоть IPv4, хоть v6? Или просто у tunnel broker-а взять IPv6 и уже сегодня радоваться?
        • 0
          сидит за NAT-ом

          Tunnelbroker (который he.net) использует протокол SIP, а значит не работает за NAT. Для работы за NAT можно либо использовать брокера через протокол AYIYA (несколько брокеров), либо тех, у которых свой клиент.
          • 0
            Да, про he я погорячился, факт, привык с ними с белых ip работать. Но варианты-то за-NAT-ные есть, чем не способ получить нормальную связность?
  • 0
    «Важно отметить, что IPv6-адресов на одном интерфейсе может быть несколько, причем это стандартная ситуация.» — В IPv4 тоже нет проблем, даже в винде навешиваются десятки адресов стандартными средствами.

    «Все IPv6-адреса делятся на две группы: линк-локал и глобал юникаст.» — А мультикаст?

    «Чистого бродкаста в IPv6 уже нет, но не нужно забывать, что глупые копеечные свичи весь мультикаст рассылают широковещательно, в итоге часть новых механизмов сводится на нет.» — А умные при включённой фильтрации незареганных групп тупо режут весь IPv6 мультик, ибо не все знают про IPv6 и MLD.

    «Во-первых, хороших IPv6-файрволов еще не так много, во-вторых, их еще нужно купить и настроить.» — А ОС и так умеют своими фаерами в6.

    «Если вспомнить IPv4, то там обнаружится три атаки, которые эффективны и по сей день в локальных сетях, — это ARP spoofing, DHCP spoofing, а также ICMP-редиректы» — Первые два легко вырезаются современными свичами (2006+ может и раньше) под корень.
    Под редирект можно ACL накидать и тоже вырежет его.
    IPv6 такие фишки есть и у других вендоров, благо они сводятся к простой ACL с заранее известными оффсетами/значениями. А если нет — спеки в руки и пишим ACL сами.

    В остальном да, в IPv6 всё феерично, прямо как в 90-е в IPv4.
    Удивительно что не вспомнили как включённый по дефолту механизм туннелирования в винде (висте) выставил сетку каких то ли госов то ли комерсов американских голым задом в инет, чем кто то удачно воспользовался.
    • 0
      В IPv4 тоже нет проблем, даже в винде навешиваются десятки адресов стандартными средствами.

      Тут есть еще интересные вещи, о которых не упоминают в статье. Например, параметр on-link у адреса. Грубо говоря, он указывает, как нужно маршрутизировать подсеть. Если у нас подсеть /64 и она on-link, то это означает, что все компьютеры доступны по мультикасту в пределах этой сети, и можно получать их MAC через NDP, а если нет on-link, то все запросы пойдут через gateway. Т.е., грубо говоря, в IPv4 вам для этого нужно бы было либо использовать /32 вместо /24 и бороться с неправильным source-адресом, когда запрос уходит на эту /24, в некоторых случаях, либо использовать arp proxy, а в IPv6 для этого свой такой вот удобный механизм.

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

Самое читаемое Разработка