Введение в IPv6

Как вы, возможно, уже догадались по моему довольному голосу, сейчас мы будем говорить про IPv6. И по большому счету говорить про него, вероятно, будет интересно, но с некоторыми оговорками. Интересно потому, что это новый протокол, который никто особо не знает, что-то мистическое, таинственное. Интересно было бы с ним разобраться. А оговорки заключаются в том, что на самом деле IPv6 — это просто новая версия протокола IPv4. Ничего в нем прям кардинально нового нету. Я думаю, что вы догадываетесь, чем IPv6 будет отличаться от IPv4. Даже если вы совсем ничего не знаете про него, вы уже понимаете, какие есть проблемы у IPv4. Это классовая адресация, которая была, ее уже, к счастью, упразднили, но это недостаток IP-адресов. Это определенные проблемы,

вызванные нехваткой IP-адресов, сложность назначения адресов на хосты, это проблема с безопасностью, это проблема с отказами в обслуживании. И на самом деле IPv6 — это не какой-то совсем другой протокол, который надо изучать отдельно с нуля. Это эволюция протокола IPv4. Он устроен внутри точно так же. Только те проблемы, которые были в IPv4, в IPv6 были решены. И они решены не какими-то совсем новыми концепциями. За очень редкими исключениями IPv6 себя ведет точно так же, как IPv4. Какие проблемы мы в IPv4 знаем? Недостаток IP-адресов — это первое, что приходит в голову. Когда авторы протокола IPv4 — это Винтон Сёрф и Джон Постел — разрабатывали этот протокол, они разрабатывали его как экспериментальный протокол, который должен был решать очень специфические задачи. Да, он должен был ориентироваться на то,

что сеть может быть большой, но авторы протокола даже близко не предполагали, что в ней могут быть миллиарды узлов. Поэтому задачи вида «объединить в единую сеть миллиарды узлов» у авторов IPv4 не было, эту задачу они не решали, и они предположили, что 2 в 32-й степени адресов гипотетически должно быть достаточно с очень большим запасом для решения той задачи, которую перед ними ставили. Если бы в какой-то момент времени им сказать: ребята, сегодня, в 2019 году, в сети порядка 15 миллиардов хостов, придумайте такой протокол, который смог бы нормально с таким количеством адресов работать. Естественно, они бы придумали тогда большего размера адреса, чтобы этих адресов получилось больше. Они придумали столько, сколько придумали. Они подумали, что достаточно будет заложить по одной большой, скажем, безумной сети на каждую страну. Они подумали, что в каждой стране достаточно будет иметь порядка сотни,

может быть, двух сотен огромных сетей и больших сетей, сколько там останется. Они предложили три размера сетей: большой, гигантский, безумный, и предположили, что для нужд военных организаций Соединенных Штатов этого будет более чем достаточно. В реальности оказалось, что недостаточно. В реальности оказалось, что после того, как гражданские стали тоже пользоваться этим протоколом, то, что мы сегодня знаем как всемирная сеть интернет, оно стало расти существенно быстрее. И поэтому то количество адресов, которое авторы протокола заложили, 2 в 32-й степени, или 4 миллиарда с небольшими копейками, это решительно недостаточно. То, что их недостаточно будет, стало понятно очень быстро. В 84-м году появляется сабнетинг, появляется отказ от классовой адресации, в начале 90-х годов появляется NAT,

мы про него еще не говорили, но обязательно поговорим чуть дальше. И за счет того, что нету какого-то единого центра, который может легко и непринужденно выдавать IP-адреса вообще всем, у нас часто есть необходимость просто взять и назначить какие-то IP-шники на какие-то хосты. И мы не хотим идти в IANA, в международную организацию, которая распределяет адреса. Мы просто хотим себе назначить IP-шники. В IPv4 появилась такая концепция частных адресов. Это адреса, которые нельзя выпускать в интернет, но их может назначить себе любой желающий. И этих частных адресов оказалось действительно супермало. Поэтому, если вдруг вы пытаетесь стыковать между собой две частные сети, у вас почти обязательно будет конфликт, что несколько сетей используют одну и ту же адресацию. В IPv4 есть родовая травма — это классовая маршрутизация. Даже сегодня, в 2019 году,

прошло уже 35 лет с момента отказа от классовой маршрутизации. Но тем не менее, так или иначе, во многих технологиях следы этой классовой маршрутизации всплывают. Я уже приводил пример про VPN в Windows: когда вы ставите VPN-туннель, и Windows додумывает маску, он ставит маску классовую. Есть еще много примеров, где вылезают эти классовые следы. Даже сегодня классовой маршрутизации уже нет, но эти самые классы сетей все еще кое-где встречаются. У IPv4 неоптимальный заголовок. Какие-то поля, которые в IPv4 есть, они откровенно не нужны, оказались по факту. Помните, какие там поля? Там фрагментация есть. А мы от фрагментации стараемся все время отказываться. Поэтому в любом пакете есть информация про управление фрагментацией, но очень мало пакетов, которые по факту фрагментируются. А заголовок все равно передается, и каждый узел обязан его проанализировать.

Он, может быть, не будет смотреть, что там написано, изучать как-то особенно пристально. Но, по крайней мере, машинное время на обработку полей по управлению фрагментацией тратить приходится. Абсолютно дурацкая чексума, которая в IPv4 закрывает только заголовок, причем закрывает очень неэффективным механизмом. Вот это все — это проблемы, которые в IPv4 есть, и с ними можно было бороться путем предложения каких-то альтернативных вариантов. С чексумами как бороться? Все выкинуть нафиг надо. Зачем чексума в IPv4 нужна? На канальном уровне протоколов, в которых не было бы своего механизма контроля доставки, качества доставки — как в Ethernet есть чексума, Frame Check Sequence, он достаточно неплохо проверяет, побились данные или не побились. Если на уровне Ethernet-а какие-то данные к нам прибежали, они, скорее всего, проверены на правильность. Поэтому на уровне IPv4 сегодня проверять отдельно заголовок на корректность

бессмысленно. Намного проще сказать: окей, что бы ни прибежало в Ethernet-е, оно заведомо правильное, оно заведомо не побившееся. Поэтому мы смотрим на любые поля, которые там есть, и любые поля мы воспринимаем как корректно заполненные. Мы просто смотрим, нам пришло или не нам, и все. Нет необходимости отдельно проверять чексумы. Протоколов, в которых действительно не было бы проверки на корректность на канальном уровне — ну, не знаю, почтовые голуби. Вряд ли их можно воспринимать всерьез. Они даже появились как шуточный экземпляр протокола. А так в любых канальных протоколах проверка есть собственная. Более того, любое вложение, которое в IPv4 можно сделать — это TCP, UDP, то, которое по факту сегодня используется — оно имеет свою чексуму. Поэтому, какие бы полезные данные мы ни передавали, нет необходимости отдельно проверять заголовок IP. Потому что вся информация, которая в IP передается в заголовке, на самом деле она дублируется, в некотором смысле дублируется, в чексуме внутреннего вложения.

Что в ICMP, что в TCP, что в UDP — на самом деле чексумы будут проверять корректность заголовка IP. Поэтому получается, что в IPv4 чексума совсем прям как-то лишняя. Минимальный MTU в IPv4 — 576 байт, гарантированный MTU, который поддерживается любыми узлами. Сегодня принято работать с пакетами существенно большего размера. Фактически мы будем воспринимать как ошибку то, что не проходят пакеты до полутора килобайт. Если мы отправляем 1500 байт, и оно не пролезает, оно требует фрагментации сегодня, можно считать, что это будет ошибка. Я вам показывал пример, что у меня в моем компьютере, на котором я провожу занятия, некоторый узел — действительно до него пакеты 1500 байт не проходят, а 1430, по-моему, проходят, 1432 мы вчера измеряли. По большому счету это ошибка.

Если бы не тот факт, что альтернативного варианта там нету, только так и никак иначе, то по большому счету это следует воспринимать как то, что не должно быть такого, что пакеты размером 1500 байт по-хорошему должны проходить без фрагментации. Но в IPv6, забегая немножко вперед, минимальный MTU поправили, его сделали 1280 байт. Гарантированно в любом случае пакеты 1280-байтовые должны пролезать в любой сетевой интерфейс без фрагментации. Абсолютно любой узел должен их обрабатывать корректно. Так. Далее. У IPv6 существенно больше адресов. Эти адреса, как следствие, стали сильно больше по размеру. Были споры, сколько именно бит сделать IPv6-адрес. 32 бита — очевидно мало. Было бы неплохо выровнять это все дело по какой-то красивой границе, типа 32 бита или 64 бита сделать его.

Соответственно, сделали в итоге 128-битные адреса. Эти адреса записываются в шестнадцатеричном виде и записываются как 8 групп по 4 разряда, разделенных двоеточиями. На картинке приведен пример IPv6-адреса. 2001, DB8, B16B, 00B5, 0000. Это все шестнадцатеричные числа, и они записываются в группы по 4. Каждая группа отделяется от соседней двоеточием. Вы можете сказать, что какой-то перебор, длинный очень адрес получился. Это неизбежное следствие того, что адресов в IPv4 мало, и следствие того, что нам пришлось делать этих адресов больше. И как следствие, сами адреса получились длиннее. Да, они стали существенно длиннее по сравнению с IPv4, но их стало существенно больше. 2 в 128-й степени — это уже не 4 миллиарда. Я даже цифру произнести не могу, сколько этих адресов. Если вдруг вы озадачитесь,

это приблизительно 10 в 40-й степени. Если я начну писать, сколько этих адресов в обычном десятичном представлении, я напишу единичку, и потом 40 ноликов. Это прям реально много. Может быть, не 40, может быть, 39 или 38 будет. Как вы понимаете, на результат это не сильно повлияет. Все равно это очень-очень много. И в IPv4 у нас адресов было мало. Как следствие, мы вынуждены были использовать какие-то механизмы по эффективному использованию этих самых IP-шников. Мы старались сделать так, чтобы адреса впустую не расходовались. В IPv6 решили отказаться от этой практики. IPv6 исходит из того, что адресов у вас заведомо больше, чем нужно на любые разумные нужды. Этих адресов столько, что даже если вдруг понадобится какой-то механизм, который будет очень интенсивно расходовать IP-адреса, этих адресов будет достаточно.

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

то эти нулевые битики можно опустить. Как с обычными десятичными числами: если у нас есть число 100, это же абсолютно то же самое, что число 0100, обычное десятичное число — что здесь написано 100, что здесь написано 100, только ведущий нолик ничего не обозначает. Равным образом и здесь. Ведущий нолик ничего не обозначает, но только ведущие нолики, не любые нолики можно выкидывать. Например, если у нас есть число 101, нолик в середине выкидывать, конечно, нельзя, что в десятичном виде, что в шестнадцатеричном — от этого изменится смысл. Старшие нолики выкидывать можно. Естественно, если у вас группа состоит из четырёх ноликов, то один хотя бы надо оставить, чтобы показать, что там что-то есть. Второе правило указывает на то, что если у нас есть несколько групп нулевых разрядов, как здесь, соответственно, три группы, которые целиком состоят из нулей, в одном и только в одном месте IP-адреса вы имеете право

все нулевые группы подряд заменить символом двойного двоеточия. В нашем случае адрес длинный, который написан на слайде, с использованием двух этих правил мы сможем сократить немножечко и записать его в несколько более коротком виде. Во-первых, первая группа 2001. Тут ничего не сокращается, она переезжает в сокращённую запись без изменений. Во-вторых, 0db8. 0db8, здесь ведущий нолик, его можно убрать, соответственно, останется просто db8. Потом b16b, ничего здесь не сокращается. 00b5, два ведущих нолика можно убрать, сокращаем просто до b5. Дальше три идущих подряд нулевые группы сокращаем до символа двойного двоеточия. И дальше 0001, три ведущих нуля, сокращаем до единицы. И получается вместо достаточно длинной записи существенно более короткая запись. На самом деле вы почти всегда можете, если вам вдруг требуются адреса, которые будут достаточно короткие,

практически всегда использовать такие короткие адреса. Это не как в IPv4. Вам дали какой-то набор IP-адресов, и вы с ним живёте. В IPv6 вам, как правило, предоставляют сразу большую сеть, и в этой сети вы всегда можете выбрать себе красивые IP-шники. Почти всегда это можно сделать, по крайней мере до такой длины записи вы всегда можете какие-нибудь IP-шники, которые вы будете использовать, сократить. Не любой адрес, понятное дело, можно сократить до такой короткой записи, но почти всегда, если вдруг у вас есть в распоряжении набор IP-адресов, какие-то адреса до такого рода записи будут сокращаться хорошо. Обратите внимание, что из этой сокращённой записи всегда можно восстановить оригинальную полную запись. Например, у нас есть первая группа 2001. Мы понимаем, что здесь ничего не сокращали, и в итоговый результат 2001 переезжает без изменений. Дальше. db8. Три символа, а должно быть четыре в группе.

Поэтому мы говорим: ведущий нолик, один сократили. 0db8. Дальше. Третья группа. b16b. Четыре разряда, ничего не сокращали. b16b. Четвёртая группа. b5. b5, соответственно, два разряда. Значит, два опустили. 00b5. Дальше. Двойное двоеточие. Означает, что некоторое количество нулевых групп подряд пропущено. И возникает вопрос: сколько их пропущено? А всего их восемь. Раз, два, три, четыре, пять, шесть, семь, восемь. В сокращённой записи у нас раз, два, три, четыре, пять групп есть. Значит, пропущено три штуки. Пишем 0000, двоеточие, 0000, двоеточие, 0000. Двоеточие, последняя группа, просто единичка. Сокращённая запись — единичка. Полная запись — 0001. Таким образом получается, что можно из полной записи сделать сокращённую и из сокращённой записи сделать полную.

Это обратимое преобразование. Мы при этом ничего не теряем. Почему ровно в одном месте адреса можно несколько нулевых октетов заменить двойным двоеточием? Почему нельзя в двух разных местах заменить двойным двоеточием? Дело в том, что если вы в двух разных местах замените символами двойного двоеточия несколько нулевых групп подряд, не будет понятно, где и сколько вы нулевых групп выкинули. Если у нас есть какой-нибудь адрес, допустим, 1::2::3, мы сделали вид, что мы в двух местах сократили несколько нулевых групп подряд. Мы считаем, сколько у нас получилось. У нас 1 группа, 2 группа, 3 группа. Значит, 3 группы есть, 5 групп нет. И возникает вопрос. Здесь двойное двоеточие и здесь двойное двоеточие. Сколько где сократили? То ли здесь 4, а тут 1. То ли здесь 3, а тут 2. То ли здесь 2, а тут 3. То ли здесь 1, а здесь 4.

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

128 бит, или 8 групп по 4 шестнадцатеричных разряда. Считайте, что этих групп у вас действительно получается 8. Если в каком-то месте сделали сокращение до двойного двоеточия, проверяйте, что вместо двойного двоеточия вы можете написать как минимум две нулевые группы подряд. Проверяйте, что двойное двоеточие, если есть, то только в одном месте. Очень подлый вопрос на экзамене: иногда в конце вам делают что-то такого плана — буковку ставят какую-то, которая не характерна для шестнадцатеричного алфавита, шестнадцатеричной записи. В шестнадцатеричной записи у нас есть цифры 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. Буквы, допустим, H там нет. И иногда бывает такое, что мы смотрим на это и думаем, что это H обозначает шестнадцатеричную запись. Нет, не должно быть такого. Мы никогда в шестнадцатеричной записи IPv6-адреса не пишем никаких других символов,

кроме самих шестнадцатеричных разрядов. И в каждой группе не должно быть больше четырёх разрядов. Меньше может быть, больше — нет. Как и в IPv4, у нас IPv6-адрес делится на две части: левую и правую. Левая называется Network ID, всё то же самое. Правая часть называется — здесь небольшое изменение по сравнению с IPv4, переименовали милицию в полицию — называется она Interface ID, а не Host ID. Связано это с тем, что в IPv4, если у нас был IP-шник, у которого мы говорили: есть левая часть Network ID и правая часть Host ID, то Host ID был уникален в пределах канала. И если у нас был узел, у которого есть два интерфейса, левый и правый, то здесь у нас был IP-шник с Network ID и каким-то Host ID, и здесь у нас был какой-то IP-шник с Network ID и, соответственно, Host ID. Получалось, что здесь у нас Host ID один, а здесь у нас Host ID другой. И это на самом деле получалось по логике не совсем идентификатор хоста.

Это получалось идентификатор конкретного интерфейса хоста в пределах канала. В IPv6 просто запись переименовали, по смыслу всё осталось то же самое, только вместо Host ID назвали это Interface ID — интерфейс конкретного хоста в пределах какого-то конкретного канала. И это более корректное, более правильное название, которое больше по смыслу подходит к конкретной сущности. Естественно, у нас может где-то проходить граница между левой и правой частью в IP-адресе. В IPv4 мы сначала предполагали, что по внешнему виду IP-шника можно угадать эту границу. Потом появились маски, которые позволяют указать, где конкретно в IP-адресе проходит граница между левой и правой частью. В IPv6 тоже есть маски, никаких классовых адресов нет. По внешнему виду IP-шника нельзя точно, гарантированно сказать, где проходит граница между левой и правой частью. И требуется, как правило, запись этой самой маски.

Маска только префиксная, вас никто не заставляет писать 255.255... или даже FFFF. Запись выглядит, к примеру, так: 2001:db8::2/32. Эта часть — IP-шник, а эта часть — маска. И, соответственно, 2001:db8 — это, если полную запись писать, 2001:0db8:0000... Просто всё, что после первых двух групп, схлопывается до двойного двоеточия. Не пугайтесь, если вдруг такое увидите. Может быть такое, что вы захотите указать какую-то сеть, и сеть будет состоять из всего одного адреса. Как в IPv4 у нас были сети /32, которые использовались для назначения на интерфейс, который никуда больше не смотрит, воображаемый интерфейс. В IPv6 такие штуки тоже бывают, например, ::1/128.

Это сеть, состоящая из одного адреса 0000:0000:0000:0000:0000:0000:0000:0001. Такой адрес специально придуман красивый для лупбеков. Лупбек — это сущность, которая переводится как обратная петля. Началось всё с того, что у вас были интерфейсы, и в этих интерфейсах у вас, как правило, были какие-то передатчик и приёмник. Как в оптике, например. Чаще всего у нас как раз двуглазая оптика. У неё одно волокно передаёт сигнал, другое волокно принимает сигнал. Если вы возьмёте оптическое волокно и закольцуете его, свой собственный передатчик замкнёте на свой собственный приёмник, получится, что у вас интерфейс сам себе отправляет данные. Всё, что отправляется передатчиком, приходит на приёмник. На физическом уровне эта штука получила название лупбек — обратная петля. И если вдруг вы это делали, то вы могли таким образом, например, проверить свой интерфейс.

Он у вас не сгорел ли? Если вдруг вы вставляете такую хитрую оптическую петлю в свой интерфейс и что-то отправляете в этот интерфейс, проверяете, видите ли вы это обратно, то, значит, интерфейс у вас работает. Но это на физическом или на канальном уровне такую штуку можно сделать. На уровне IP есть возможность даже не отправлять ничего в физический интерфейс, не отправлять никакие фотоны в оптику, а сделать воображаемый интерфейс, у которого нет никакого физического представления. И такой интерфейс будет называться лупбек-интерфейс. Это интерфейс, который всё, что в него отправляется, сам немедленно обратно же и принимает. Только это происходит не путём отправки по проводу, который обратно в вас смотрит, а путём просто перекладывания IP-пакетов внутри стека IP.

Если вы делаете такой лупбек-интерфейс, то он появляется, он всегда находится в состоянии up. Если вы делаете такой интерфейс, то это будет интерфейс с воображаемой петлёй. Физически такой штуки не будет, но воображаемая петля будет. Всё, что вы в лупбек отправите, всё на вас же и придёт. Есть ещё лупбек-адрес. Это отдельная сущность, которая называется ::1 в IPv6 или все адреса в сети 127.0.0.0/8 в IPv4. Лупбек-адрес — это такой специальный адрес, который не вешается ни на какой интерфейс. Это адрес, и на уровне стека, если вы попытаетесь отправить на этот адрес какие-то пакеты, они немедленно на вас придут. У вас даже они в интерфейс никакой не выйдут. Они просто внутри самого стека IP немедленно будут восприняты как адресованные именно вам. В IPv4 у нас были любые адреса, которые начинаются на 127.

Это адреса, если хотите, принадлежащие вообще любому узлу, каждому узлу. В IPv6 от такого большого количества адресов отказались, сделали только один адрес — ::1. В IPv6 мы можем указать маску, и эта маска будет указывать на то, где в конкретном IP-адресе у нас проходит граница между левой и правой частью. Если вдруг вы немножко смущаетесь размером IP-адреса и размером маски, я вас немножко могу утешить. IPv6 специально сделан для того, чтобы не приходилось заниматься достаточно скучной операцией по сабнеттингу, который мы в IPv4 делали, когда выкраивали один битик от Host ID и переносили его к Network ID. У нас получались всякие разные кривые маски — 17-е, 26-е. В IPv6, как правило, на конечные хосты назначаются адреса с 64-й маской.

Адрес делится ровно пополам. У нас всего 128 бит, ровно пополам делится адрес, и, соответственно, Network ID — это левая половина адреса, Interface ID — это правая половина адреса. И тут вы мне можете сказать: а что за наркомания? Ладно, под Network ID 64 бита — это достаточно много, потому что у нас самих сетей может быть много, и 2 в 64-й степени — это действительно дофига. Но кому пришла в голову идея под Interface ID 64 бита выделять, потому что это означает, что у нас в пределах одного канала может быть 2 в 64-й степени абонентов. А это не просто дофига, это невозможно много. Такого количества узлов в мире вообще не бывает. Это число приблизительно совпадает с количеством молекул, из которых состоит поверхность Земли. Это заведомо больше, чем кто-либо может вообще себе представить. И на самом деле в этом есть глубинный смысл, который заключается в том,

что мы можем не заботиться о том, чтобы экономить адреса. Мы можем просто случайным образом выбрать себе IP-шник в этой сети, с /64, и он почти наверняка будет свободен. В IPv4 мы вынуждены были иногда заниматься выискиванием свободного IP-адреса. У нас есть /24 сетка, мы говорим: ага, 254 адреса у нас есть в /24 сети. Первый вроде занят, это, наверное, хост, шлюз по умолчанию. Второй – это какой-нибудь сервер. Третий – это какой-нибудь другой сервер. Какой бы нам IP-адрес выбрать? В IPv6 выбирайте любой. Он будет свободен. Потому что там адресов так много, что вероятность того, что кто-то выбрал такой же адрес, как и вы, если вы его выбрали достаточно случайно, она нулевая. И на этом основаны многие свойства протокола IPv6. В частности, сразу можно представить себе первое свойство – это безопасность. Потому что в IPv4 за счёт того, что адресов мало, а узлов, которые хотят их использовать, много, если взять и ткнуть произвольный адрес, он будет занят, и он будет занят каким-то узлом.

Например, можно взять и пересканировать вообще весь интернет. Да, это займёт немного времени, но просто по опыту могу вам сказать, пересканировать весь интернет на предмет того, какой IP-адрес отзывается, какой не отзывается, и самый простой скан провести, какие порты открыты, эта штука занимает примерно пару месяцев. Просто вообще весь IPv4-интернет перебрать по всем портам – задача не просто выполнимая, а она абсолютно реальная, она реализуема очень часто. И если вы просто выпустите какой-то узел в интернет, с очень большой вероятностью, буквально через полчасика на вас кто-то будет уже нападать и пытаться вас посканировать, посмотреть на то, какие у вас порты открыты. Нет ли у вас каких-то открытых портов с сервисами, на которые есть хорошо известные уязвимости. Поэтому в IPv4 такая проблема была, в IPv6 её нет, потому что если вы случайным образом выбираете IP-адреса, перебирать даже одну единственную /64 сетку – это невозможный объём работы.

Даже если вдруг будет идти адресная атака именно на вас, кто-то будет знать, какой диапазон адресов будет именно у вас, найти даже хотя бы один узел атакующему будет очень тяжело. Более того, в IPv6 у нас, в отличие от IPv4, нет проблем с дефицитом адресов, поэтому узел может взять много IP-адресов себе, прямо много, и он может их на лету менять. И на этом тоже будут основаны некоторые забавные свойства. В IPv6 у нас есть разные адреса, разные по смыслу. На самом деле в IPv4 тоже есть разные по смыслу адреса. Есть в IPv4, например, адреса, которые маршрутизируемы в интернете. Просто обычные интернет-адреса, мы их называем иногда белыми. Есть адреса, которые мы называем частными или серыми. Вы, наверное, знаете, может быть, знаете, может не знаете. 10.0.0.0/8.

172.16.0.0/12. И 192.168.0.0/16. Эти адреса иногда называют диапазоном RFC 1918. Это хорошо известный номер RFC, пожалуй, его стоит знать. Это как раз обозначение этих частных адресов, диапазона частных IP-адресов, которые вы можете использовать по своему усмотрению. Но есть ограничение, что эти IP-адреса нельзя выпускать в интернет. И есть дополнительное расслабление по сравнению с этим ограничением, что если очень сильно хочется, то можно, но с NAT. В IPv6 NAT был признан абсолютным мировым злом, от которого следует всеми силами отказываться, пока есть такая возможность. Все технологии, которые могли бы использовать NAT или могли бы его не использовать, сделаны таким образом, чтобы NAT использовать было не просто не нужно, но и нельзя.

Поэтому в IPv6 можно с натяжкой сказать, что NAT нет. Он там, конечно, есть, но он очень специфический. И, соответственно, есть адреса global unicast, которые являются белыми адресами. Есть адреса unique local. Это адреса серые по смыслу, как RFC 1918. Это адреса, которые действительно в пределах вашей сети, но совершенно не факт, что они уникальны, и совершенно не факт, что кто-то ещё не назначил себе такие же IP-адреса. При этом в IPv4 была достаточно частая проблема, связанная с тем, что частные сети, как правило, имеют пересекающиеся диапазоны. Классический пример: сеть 192.168.1.0/24. У вас есть сеть такая, 192.168.1.0/24. И у вашего соседа Пети тоже такая же сеть, 192.168.1.0/24. И вы хотите их состыковать между собой.

У вас ничего не выйдет, потому что адреса пересекаются. И почему вдруг узел внутри одной сети должен будет посылать какой-то пакет в другую сеть, а не остаться в своей собственной сети? Вот 192.168.1.13 — хост, который он хочет нащупать. Узел 1.12 хочет найти узел 1.13. Почему вдруг он будет отправлять запрос в туннель на роутер, который связывает две эти сети? Почему он не будет его ARP-ом пытаться нащупать? Да не почему, он будет пытаться нащупать его ARP-ом. Поэтому если вдруг вам требуется делать такое взаимодействие, это приведёт к такому количеству костылей, что проще плюнуть и отказаться. В IPv6 пытались с этой проблемой побороться. Не то чтобы уж очень успешно, но тем не менее попытка такая была. И эти unique local адреса, мы про них сейчас будем дальше чуть-чуть говорить, это адреса, которые с некоторой вероятностью будут уникальные, если вы будете их назначать по какой-то разумной, правильной логике. Если у вас есть какая-то частная сеть, у вашего соседа есть какая-то частная сеть,

и вы хотите две частные сети состыковать, с большой вероятностью, если вы сделали всё правильно, у вас эти диапазоны не будут пересекаться, и корректно будет работать маршрутизация между этими двумя сетями. Есть адреса, которые называются link-local unicast. Это адреса, которые действуют только в пределах канала. На самом деле в IPv4 тоже такие адреса есть. 169.254.0.0/16. Иногда про такие адреса говорят, что это адреса APIPA. А ещё иногда говорят, что если вдруг у вас есть такой адрес APIPA, то это всё равно что адреса у вас нет. Что вы адрес не получили, у вас никакого адреса нет, потому что вы смотрите список своих IP-адресов и видите там 169.254. На самом деле эти адреса есть, они сравнительно нормальные. Единственное, что они не маршрутизируемые. Вы не можете с таким адресом отправить пакет, который пройдёт через маршрутизатор. Это делать запрещено.

Link-local unicast адреса — это как раз по смыслу такие же адреса, которые действуют только в пределах канала и которые используются, как правило, для специфического междумашинного взаимодействия. Есть multicast-адреса, тоже специальный отдельный выделенный диапазон, как в IPv4. В IPv6 тоже есть отдельный диапазон мультикастовых адресов. Есть всякие специальные хитрые адреса, специально для некоторых нужд предназначенные. Например, адрес ::1. Я уже сказал, что это адрес loopback, он всегда принадлежит именно вам. Если вы пытаетесь отправить пакет на такой адрес, вы его сами и получите. Он ни в какой интерфейс не уйдёт, его прямо стек IP на себя завернёт сразу. Есть адрес :: просто. То есть :: и всё. :: — и вот это весь IP-адрес. Такая вот коробочка. На самом деле это адрес специфический, обозначает то же самое, что в IPv4, когда мы используем адрес 0.0.0.0.

Мы хотим указать, что у нас нет своего IP-адреса, мы его только собираемся получить. Так же будет работать и в IPv6 эта штука. Если вы указываете в качестве адреса источника адрес :: или адрес всех нулей и /128, то вы по факту указываете, что у меня нет адреса, я хочу его получить или что-то ещё с ним сделать. Global unicast адреса – это самые нормальные, самые привычные адреса. Это адреса, которые маршрутизируются в интернете. Полный аналог нормальных публичных белых адресов, тех, которые есть в IPv4. В IPv4 у вас есть адрес, например, 8.8.8.8. Это белый адрес. Мы все его знаем, что это адрес из интернета, принадлежит компании Google, на нём работает DNS-сервер, и если вы хотите, вы можете его попинговать, и он будет пинговаться, потому что он в интернете.

Если эта штука не отвечает, значит, либо Google умер, либо у вас интернет не работает. И часто пинг 8.8.8.8 символизирует собой доступность интернета. Абсолютно такая же штука есть в IPv6. Адреса, которые работают в интернете, которые можно выпускать в интернет, которые доступны через интернет, они будут входить в такой блок. 2000::/3. Если вы посмотрите на эту запись 2000::/3 и вспомните, что это шестнадцатеричная запись, то есть двойка шестнадцатеричная, ноль шестнадцатеричный, ноль, ноль, вы сможете фактически представить себе, из каких именно битов состоят такие адреса. Давайте первую группу, первый октет, если хотите, запишем в двоичном виде. Двойка записывается очень просто: 0010. Дальше 0 записывается как 0000.

Ещё один 0 записывается как 0000. И ещё один 0 записывается как 0000. Вот первые 16 бит IP-адреса 2000:: они вот такие. Если мы говорим, что публичные адреса начинаются на такие же 3 бита, как адрес 2000::, то мы считаем: 0, 0, 1. Вот такие они будут: 001. Соответственно, остальные биты могут быть любыми. Нам требуется у публичного адреса совпадение только с первыми тремя битами. И эти первые 3 бита должны быть 001. Поэтому любые адреса, начинающиеся на битовую последовательность 001, это адреса, соответственно, маршрутизируемые в интернете. Как быстро и непринуждённо определить, является ли адрес публичным или каким-то ещё? Можно посмотреть, что если у нас адрес начинается на битовую 001, какие именно формы такой адрес может принимать?

Самый маленький адрес, который будет входить в этот блок, это будет сам адрес 2000:: и ещё куча нулей. Самый большой адрес, который будет входить в такой блок, будет начинаться на 001, а дальше он будет состоять из кучи единиц. Мне лень писать все единицы, но я напишу первые 16 разрядов. Это шестнадцатеричное число 3FFF. Мы можем сказать, что 3FFF – это первая группа самого последнего адреса, который является публичным. Все адреса, начиная с 2000:0000:0000:0000:0000:0000:0000:0000, по 3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF — это всё публичные адреса. Они начинаются либо на двойку, либо на тройку. Всё, что начинается на двойку или на тройку,

то есть это либо такие первые четыре разряда, либо такие первые четыре разряда. Вариантов немного. Всё, что начинается на двойку или на тройку – это всё публичные адреса. Эти публичные адреса будут выстроены в некоторую иерархию. У IPv4 была проблема, заключающаяся в том, что адресов мало, и для того, чтобы эффективно раздавать IP-адреса, международная организация, которая занимается распределением IP-адресов, их раздаёт маленькими блоками. У нас есть какая-то компания в условной Америке. Она хочет получить адреса, она должна будет обратиться к своему регистратору, и он должен будет выдать ей адреса. Компания в России хочет получить IP-адреса. Она обращается к европейскому регистратору, и регистратор даёт ей IP-адреса. Эти адреса, которые выдаются, выдаются маленькими блоками, но за счёт того, что адресов вообще мало, эти блоки достаточно быстро съедают всё доступное регистратору адресное пространство. Поэтому регистратор от IANA тоже получает эти блоки,

которые он раздаёт, достаточно маленькие. И получается как следствие, что у нас в интернете фактически IP-адреса могут произвольно чередоваться по стране назначения. Если взять и все IPv4-адреса представить себе в виде числовой оси, то не будет такого, что вот эти все адреса – это Америка, вот эти все адреса – это Европа, вот эти все адреса – это Китай, и вот здесь всё остальное. К сожалению, такого нет, а очень сильно хотелось бы. По факту то, что будет наблюдаться… Ой, случайно удалил эту числовую ось. По факту то, что будет наблюдаться: вот здесь кусочек Америка, вот здесь кусочек Европы, здесь кусочек Африка, здесь кусочек Латинской Америки, здесь кусочек побольше – снова Америка, здесь кусочек поменьше – снова Европа. И они реально вразнобой идут. И существуют базы, которые указывают на то, какие блоки какие регистраторы получали, как они их раздавали. И эти базы достаточно объёмные, потому что в итоге получается, что нельзя сказать, что у нас сначала большой, прямо огромный блок Европы, потом большой блок Америка, внутри блока Европы большой блок получает Россия, следующий блок — Германия, кто-то ещё. Нет такого, к сожалению, хотя хотелось бы, конечно.

В IPv6 эту штуку удалось реализовать, и в IPv6 все адреса будут большими блоками распределяться по региональным регистраторам. Есть международная организация, которая занимается распределением адресов, и она, если мне память не изменяет, Internet Assigned Numbers Authority, или что-то в этом духе, та самая организация, которая раздаёт IP-адреса, следит за тем, чтобы эти адреса не пересекались. Она берёт большие блоки адресов и раздаёт их региональным регистраторам. Региональных регистраторов всего пять. Это европейский RIPE, североамериканский ARIN, дальше Латинская Америка — LACNIC, Asia Pacific — APNIC, и AfriNIC. Пять региональных регистраторов, которые заведуют всем, что происходит в их регионе, и дальше к этому региональному регистратору приходят так называемые LIR,

Local Internet Registry, и запрашивают у регионального регистратора блок из его диапазона. RIR получают от IANA блоки как минимум /23 или крупнее. По факту в некоторых случаях можно наблюдать, что, например, американский регистратор получал в своё время /12 сеть. Это достаточно крупные блоки. Дальше эти блоки начинают резаться на части RIR-ами и раздаваться LIR-ам. LIR может от регионального регистратора запросить блок /32. И опять же, если вы суперкрупный LIR, вы можете сказать: зачем мне /32 сеть, потому что я её быстро израсходую. Я хочу намного больший блок получить, чтобы мои клиенты могли ко мне обращаться, и я не бегал бы за каждым чихом к региональному регистратору, потому что мои клиенты эти мелкие блоки будут расходовать буквально по одной штуке в день. Поэтому может быть такое, что LIR приходит к RIR и говорит: дай мне сразу большой блок.

И история знает случаи, когда LIR-ы получали блоки до /19 размера. Далее. Когда вы клиент, вы приходите к LIR и говорите: LIR, дай адреса. Либо вы назначаете адреса, потому что вы провайдер, либо вы можете давать эти адреса в аренду. В общем, смысл именно такой, что фактически конечные пользователи получают адреса именно у LIR-ов. Если вы юрлицо, то практика показывает, что вы получаете блоки /48. На самом деле /48 блоки надо получать всем. Неважно, юрлицо, физлицо. А если вы больше, то вы можете попросить побольше. Но по факту очень часто в индустрии люди, которые занимаются дизайном сетей, они не очень хорошо знакомы с принципами устройства IPv6. И они росли на IPv4. Они говорят: ну, /48 сетка, с учётом того, что клиент на свои хосты будет назначать /64 сетки, это 65 тысяч различных подсетей.

Мы выдаём клиенту 65 тысяч подсетей, каждая по безумному количеству IP-адресов. Это как бы много, это неразумно. И у нас так слишком быстро будет заканчиваться наше адресное пространство. Определённая логика в этом есть, поэтому по факту вы можете встретить ситуации, когда клиенты не будут получать /48, они будут получать что-то поменьше. Но есть рекомендация юрлицам меньше чем /56 сетку не давать, потому что юрлицу надо будет делать, скорее всего, разделение сетей на подсети. В IPv6 NAT нет, поэтому любой узел, который должен будет выйти в интернет, должен получить свой собственный IP-адрес. И если у вас, соответственно, 100 VLAN-ов, и в этих 100 VLAN-ах сидят пользователи, то вам придётся сделать как минимум 100 подсетей. Чтобы не заниматься заимствованием бит от host ID под network ID,

у вас уже есть штатное место, куда вы можете записать фактический номер подсети. И если вы физлицо, в принципе, вы тоже должны получать такого же размера блоки, /48 или /56. Но провайдеры, которые занимаются физлицами, они хорошо понимают, что по факту чаще всего внутри, допустим, квартир или частных домохозяйств не будет разделения на виланы, и чаще всего там будет всего одна внутренняя сеть, и поэтому часто клиенты физлица получают блоки по 64-й маске сразу, которые уже ни на что порезать не получится. А конечный пользователь, конечный компьютер, терминал, он должен получить адрес именно с 64-й маской. Поэтому если у вас есть всего одна сетка с 64-й маской, то дальше вы уже ничего порезать из этого блока не сможете. Казалось бы, там много-много различных айпишников и битиков в этих айпишниках, которые прямо просятся для того, чтобы их порезали, но очень много механизмов у клиентских устройств

будет основано на том, что они получают именно 64-ю маску. Если вы даете им какую-то другую маску, механизмы эти будут ломаться. Если мы возьмем какой-нибудь публичный айпишник, то у него есть четкая структура. Сначала первые три битика 001, они вот здесь 001, они зафиксированы 001. Дальше какая-то часть, которая фактически указывает на то, что этот блок принадлежит какому-то конкретному регистратору. Допустим, это блок, который получился во время RIPE. Дальше этот RIPE раздает свои айпишники LIR-ам, локальным регистраторам, и какой-то локальный регистратор, к примеру, МТС, получил блок адресов от RIPE и раздает его своим клиентам. Кто-то пришел в МТС, какое-то ЗАО «Ромашка», и говорит: я хочу получить от тебя адреса. И вот это — блок «Ромашки».

Вот это идентификатор внутри самого IP-адреса, который указывает на то, что в конкретном локальном регистраторе был получен блок адресов, и он был выдан именно ЗАО «Ромашка». Дальше вот это — фактически subnet ID. Subnet ID. И вот вся эта часть — это interface ID. Interface ID. Вы по внешнему виду адреса можете достаточно много про этот адрес сказать. Вы можете сказать, откуда взялся этот адрес, из какого региона он пришел, как минимум. По первым каким-то битам адреса вы можете сразу определить, на что похож этот адрес, на какой регион он похож. Если вы знаете, как устроен ваш регион, как устроен, допустим, блок вашего регистратора RIPE, вы можете сразу определить в некоторых случаях, от какого провайдера пришел конкретный пакет. Вы сразу видите, что некоторые пакеты приходят прямо хорошо заметные,

условно говоря, с Билайна или из МТС. Зачем физлицам одна сеть, которую никак нельзя поделить? Пришел вопрос. Физлицу надо же какую-то сеть иметь. Он получает одну сетку и использует ее. Так, дальше. Опять же, если у нас есть какие-то IP-шники, которые в свое время получила ЗАО «Ромашка», мы можем с некоторой вероятностью сказать, что все IP-шники, начинающиеся на вот это, они все будут ромашковские. Не обязательно они будут приходить из одного и того же VLAN, у них, условно говоря, номер VLAN сюда можно положить. Но мы можем, опять же, если мы знаем, как устроена адресация у нашего провайдера, мы можем определить, какие IP-шники принадлежат какому клиенту. И опять же, вот здесь, если мы захотим, мы можем номер VLAN вкладывать. И поэтому можно будет сказать, что некоторые пакеты, которые приходят, они, похоже, приходят из одной и той же компании, просто из разных VLAN. Физлицо — да, это прямо абонент.

Здесь всё это прямо про абонентов речь. Абоненты конкретного провайдера. Провайдер — это LIR. Так, далее. Unique Local адреса — это адреса, которые в интернете не маршрутизируются. Если у вас есть IPv4-адрес, он на компьютере на вашем, скорее всего, частный. Он не публичный, он не белый. Он как раз из этого диапазона RFC 1918. На десятку он начинается, или на 172 там чего-нибудь, или на 192.168. Но мы нагло пользуемся тем, что эти адреса в IPv4-мире можно выпустить в интернет, если их перебить. Про то, как это происходит, мы будем говорить отдельно, но мы будем использовать механизм NAT. В IPv6 NAT нет. NAT нет вообще, и не завалялось, и не договоримся. В IPv6 NAT нет. Если вдруг вы хотите абоненту предоставлять услугу выхода в интернет,

вашему какому-нибудь компьютеру, то вы должны, обязаны будете выдать ему белый адрес. В IPv4-мире это очень редкое явление, чтобы на абонента прямо сразу назначался белый IP-шник. А в IPv6 это единственный способ обеспечить доступ для потребителя в интернет. И здесь очень часто у людей возникает некоторый дискомфорт. Они говорят: как же это так, белый IP-шник каждому прямо отдельно. Это же нас прямо жестоко поимеют сразу, немедленно, как в IPv4: мы вешаем белый IP-шник на узел, и сразу нас начинают щупать за вымя. Что у нас за порты открыты, нет ли у нас каких-то уязвимостей. И здесь вы должны понимать, что в IPv6 вас никто сканировать не будет. Невозможно вас просканировать, если у вас случайно выбранный IP-шник. Никто никогда до IP-шника не сможет достучаться. В IPv4 можно просканировать весь интернет, и можно случайным образом, выбрав IP-шник, начать его сканировать, и там, скорее всего, что-то будет. В IPv6 за счет того,

что адский объем адресов, и если вы случайно выбираете из этого адского объема адресов какой-нибудь IP-шник, никто никогда не сможет понять, какой адрес вы выбрали. И даже если вдруг специально на вас будут охотиться, будут специально вашу /64 сеть сканировать, никогда не смогут найти тот самый IP-шник, который принадлежит какому-то конкретному узлу, или вообще какому-нибудь узлу. Потому что настолько рыхло расположены адреса, что почти всегда, когда вы будете видеть какой-нибудь диапазон адресов, там почти все IP-шники будут свободны. Они не просто почти все, они все с очень маленькой оговоркой. Однако иногда бывает нужно в каких-то специфических целях обеспечить работу IPv6-сети, и при этом не хочется получать публичные IP-шники. В некоторых случаях это бывает нужно. И для этого у нас есть механизм, который называется Unique Local адреса, Unique Local Unicast.

Это адреса Unicast, нормальные, назначаются по схеме такой же, как и публичные, но они не могут выходить в интернет. Это по сути своей аналог тех самых десяток, 192.168 и прочего. Они входят в блок FC00 по седьмой маске. И здесь опять же, F — это у нас 1111, C — это 1100, дальше 00000 и 00000. И здесь мы смотрим, седьмая маска — это значит первые 7 битиков вот такие вот должны быть. Это адреса, начинающиеся с FC или FD. И этот диапазон FC00 по седьмой маске был разделен на две части. Первая часть, FC00 по восьмой маске, была выдана под так называемые IANA Managed адреса. Смысл этого диапазона был в том, что если вдруг вы хотите получить IP-шники, которые не публичные,

их нельзя выпускать в интернет, но вы хотите быть уверены, что точно и гарантированно такие IP-шники ни у кого не будут встречаться. Например, для того, чтобы можно было взять и любые две сети состыковать между собой по этим Unique Local Unicast-овым адресам, и это будет не интернет-взаимодействие, а какое-то частное межсетевое взаимодействие. Вы могли бы всегда это сделать гарантированно, чтобы ваши IP-шники не пересекались с какими-то другими IP-шниками. И эти IANA Managed адреса вы должны были получать, вы за них должны были платить деньги. Понятное дело, что наркоманов, которые готовы были бы заплатить денег организации, которая управляет интернетом, за право использовать адреса, которые не маршрутизируемы в интернете, их нашлось крайне мало. Поэтому эту штуку упразднили, она сейчас считается deprecated. Вы это сделать сейчас уже не можете. А оставшуюся половину диапазона FD00 по 8-й маске любой желающий может использовать для своего хотения. Но при этом есть ограничение, рекомендация. В стандарте написано, что вы должны это делать.

Там есть способ сказать, что да, вы всё так и сделали, просто получилось очень специфическим образом. Короче говоря, вы должны будете делать так, чтобы у вас из этого диапазона FD00 по 8-й маске адреса выбирались не случайным образом, а вполне конкретным. Для того, чтобы обеспечить наибольшую вероятность того, что ваши адреса не будут пересекаться с чем-нибудь еще. Что если вдруг у вас есть какая-то частная сетка, и у вашего соседа есть частная сетка, и вы себе сделали FD чего-то там, и сосед сделал FD чего-то там, чтобы эти FD чего-то там получились разные. Что если вдруг вы захотите их состыковать между собой, у вас не будет конфликта адресов. В IPv4 это, я уже показывал, было действительно большой проблемой, и зачастую даже гигантские корпорации с этим сталкивались и ловили очень большие трудности. Классический пример — это Facebook, который купил Instagram, и выяснилось, что и у Facebook,

и у Instagram одинаковая адресация. Поэтому очень долго Instagram не был интегрирован в фейсбуковскую инфраструктуру, потому что у них, да, инфраструктура, использовали одинаковую адресацию, и стыковать напрямую эти две сети было невозможно. Ну, вот потом, естественно, это все рано или поздно синтегрировалось, но сколько крови пролил Facebook для того, чтобы это сделать, мы даже не знаем. Я думаю, что они как раз перешли на IPv6, и примерно тогда же это все и произошло. Вот. Ну, соответственно, какой механизм там нужно будет использовать для того, чтобы частные адреса, вот эти вот FD, у вас были не уникальные. В смысле, наоборот, уникальные. Вы должны будете взять некий компьютер, у которого есть, например, серийный номер или MAC-адрес, или какой-то еще уникальный идентификатор, может быть, инвентарный номер какой-то. Что-то, что у него есть уникальное, что у других компьютеров было бы заведомо отличное. Дальше вы должны взять текущее время в Unix формате и, соответственно,

записать его в каком-то виде. После чего вы должны взять хэш от серийного номера компьютера и даты текущей. И у вас получится какой-то набор относительно случайных битиков. И, соответственно, дальше вы должны взять от этого хэша 40 бит. И после чего приклеить к 8 битам вот этим самым FD. То есть вы получаете таким образом 48-ю сетку, которая, ну, с очень большой вероятностью будет уникальной. Ну, естественно, гипотетически вы можете взять ровно этот механизм. То есть никто вам не мешает взять, выйти, не знаю, в полночь на кладбище на перекресток трех дорог, взять черную кошку, положить ее, начертать пентаграмму над ней. Дальше взять компьютер с неким серийным номером, начинающимся на 666, написать текущее время в Unix формате, посчитать от этого дела хэш. Ладжи, может получиться число 000000000.

Может такое произойти? Может. Поэтому может ли такое быть, что вы возьмете сетку, например, FD002.ч slash 48. Ну, вот так получилось. Вот случайно так получилось, что получилось все нулевые результаты. Ну, может такое произойти? Может. Кто сказал, что не может? Ну, и поэтому очень часто вы будете наблюдать именно то, что вот FD002.48 это вот сетка, которая по факту будет использоваться очень и очень часто в предприятиях. Ну, понятное дело, люди, которые используют такую красивую сеть, они с одной стороны получают, как итог, очень красивые адреса, например, FD002.1. Вот такой очень красивый адрес. Если вдруг вы запоминаете IPv6 адреса, если вдруг вы должны часто диктовать IPv6 адреса, то вот это вот, это продиктовать вообще как нечего делать. То есть очень красивый адрес, это легко диктуется, легко запоминается, но недостатком является то,

что вы сами себе раскладываете грабли, от которых авторы протокола стремились, соответственно, всех избавить, что вы создаете сложности в дальнейшем для стыка сетей между собой. Ну, и еще один момент заключается в том, что вот эти вот красивые адреса, это, конечно, прикольно, что они красивые, но они по факту никакой пользы не несут. Если вы используете IPv6, у вас с вероятностью единица в сети есть DNS-сервер. Вы можете сделать красивые DNS-имена и заставить ваш DNS-сервер хранить некрасивые IP, но напротив каждого IP-шника у вас будет красивая, соответственно, человекопонятная DNS-метка. И вы можете не пингать, там, ping fd002.1, сервер красивый с красивым IP-шником. Вы можете использовать ping, не знаю, switch1.company.local, и у вас будет пингаться тот же самый IP-шник, но только вы не будете его запоминать. И поэтому по факту нет особой потребности

в том, чтобы делать человека понятный, человека запоминаемый IPv6-адреса. У меня есть любимая поговорка, что IPv6-адреса запоминает только DNS-сервера и наркоманы. Ну вот, сами принимайте решение. Вы хотите быть DNS-сервером или вы хотите быть наркоманом? Вот. Ну и link-local-адреса, третья пачка адресов, которую мы будем рассматривать в нашем курсе, это, соответственно, адреса уникальных пределах канала. Они не маршрутизируются вообще. Возникает вопрос, зачем нужны немаршрутизируемые адреса? И здесь можно вспомнить то, зачем были придуманы адреса 169.254.0.0 по 16-й маске в IPv4. Если вы вдруг когда-нибудь сталкивались с вот этими вот IP-шниками, то, соответственно, вот они называются IP-по Automatic Private IP Addressing. Они назначаются в тех ситуациях автоматически, когда у вас узел настроен на получение IP-адреса с DHCP сервера, но у него не получается это сделать. То есть у нас есть DHCP сервер,

который раздает адреса, есть какой-то компьютер, который хочет получить с DHCP сервера адрес, есть некая сеть, которая их соединяет. Ну, вот, соответственно, что-то пошло не так. То ли здесь у нас трафик не ходит, то ли здесь не ходит, то ли там, не знаю, VLAN какой-то кривой попался, то ли сервер сдох. И вот в этой ситуации компьютер пытается докричаться дай адрес, дай адрес, шлет дисковеры, ему либо не приходят офферы, либо приходят отлупы. Ну, в общем, рано или поздно он говорит, я все, я сдаюсь. Я пытался получить IP-шник, бог видит, но у меня не получилось. И он себе придумывает адрес 169.254 и дальше два каких-то случайных отцета. Вот эти вот адреса часто воспринимаются администраторами как то, что адреса нет никакого. Но на самом деле это адрес, который автоматически сгенерирован. И эти адреса, они хоть и не маршрутизируемые, не могут выйти через роутер куда-то там в интернет, и они не могут быть использованы для совершенно произвольных задач. Вы не можете, например, их в DNS прописать. Ну, потому что, а как их пропишешь, да?

Если не работает ничего. Но с этими адресами будут работать какие-то механизмы автообнаружения соседей. То есть там в сетевом окружении компьютеры будут видны. Будет работать, например, шаринг принтеров, шаринг папочек. И хотя бы какое-то взаимодействие у вас в сети будет происходить. Но для того, чтобы вот эта вот штука эффективно работала, вам нужно, ну, фактически, автоматическое обнаружение соседей. И по факту, это машины между собой будут использовать Эти IP-адреса. Та же самая история и в IPv6. У вас есть блок FE80 по 10 маске. И адреса, которые входят в этот блок, используются для междумашинного взаимодействия, для того, чтобы автоматически обнаруживать соседей и с этими соседями что-то делать. И эти адреса нужны именно для каких-то специфических задач. Например, взять и обнаружить все роутеры в сети. Вы будете при этом использовать мультикаст,

опять же, немаршрутизируемый, но вы должны будете отправить какой-то пакет с неким адресом источника. В IPv4 мы не могли мультикастовый пакет отправлять вообще без адреса источника. А здесь можно. И у нас для взаимодействия внутри канала всегда есть link-local-адреса. Они генерируются автоматически. Если у вас есть компьютер и у него есть интерфейс, на котором мы IPv6 включили, то этот адрес не надо никак получать. Он генерируется автоматом. У него левая часть — FE80, а правая часть, 64 бита, совершенно случайно придуманы. И поэтому вероятность того, что будет пересечение IP-адресов и конфликт IP-адресов, она нулевая. Опять же, потому что можно просто случайно выбрать 64 бита. Никто такие 64 бита, как вы, никогда больше не придумает. Поэтому у всех будет уникальный адрес. Любые два узла, которые будут находиться в одном канале, имеют свои уникальные адреса. Они могут нащупать друг друга с помощью мультикаста. Что ещё надо? И здесь ещё один момент,

который я хотел указать. В IPv4 у нас нормальной ситуацией было то, что на интерфейсе есть всего один адрес. И либо это APIPA, либо нормальные IP-адреса. И поэтому очень часто люди не понимают, что на самом деле адресов в IPv4 в принципе может быть много на интерфейсе. Но соответственно, либо нормальный IP-адрес, либо APIPA в IPv4 — такая логика работала. А в IPv6 у вас не работает логика либо одно, либо другое. У вас может быть много адресов одновременно. Они могут быть самых разных типов. Они могут быть link-local, более того, link-local адрес всегда есть на интерфейсе. У вас может быть белый IP-адрес для хождения в интернет, серый IP-адрес для хождения в какие-то свои частные зоны в компании, которая скрыта от всего интернета. У вас может быть несколько разных белых IP-адресов для разных, например, провайдеров, чтобы вы могли с использованием разных адресов ходить через разных провайдеров в интернет разными трассами. Может быть такое, что у вас

есть целая пачка IP-адресов, которые используются для каких-то служебных нужд. Например, вы хотите продемонстрировать, что у вас есть определённый сертификат, определённый публичный ключ. Вы придумываете себе такой IP-адрес, который соответствует этому публичному ключу. Вы тем самым, используя этот адрес, задекларируете, что у вас такой ключ есть. И вы эти адреса на лету можете менять. Этих адресов у вас может быть реально много. Нет никакой проблемы в том, что у вас на интерфейсе может быть 10, 20, 50, 100 миллионов адресов. Это нормально. Нет проблем с экономией адресов. Поэтому у вас на интерфейсе будет обязательно FE80 адрес, и если всё хорошо, у вас есть какой-то ещё дополнительный адрес для хождения в интернет, а может быть даже и не один. И есть адреса, которые для каких-то служебных нужд тоже будут нужны. Это нормально, это не проблема. И с link-local адресами есть одна особенность,

заключающаяся в том, что вы при работе с ними, если вы человек, и вы хотите, используя link-local адреса, вести какое-то взаимодействие, вы должны всегда указывать интерфейс, с которым ведётся взаимодействие. Если говорить про адрес, FE80, двоеточия, один, два, три, четыре, двоеточия, пять, шесть, семь — какой-то такой адрес. Дальше вы должны указать интерфейс. Если мы говорим про Cisco, там Serial один дробь ноль — вот так записывается. Через процент указывается интерфейс, с которого пакеты будут уходить с этими link-local адресами. Проблема в том, что на всех интерфейсах используется одна и та же сеть FE80. И соответственно, если у вас есть узел, у которого есть левый интерфейс и правый интерфейс, и здесь FE80 адреса, и здесь FE80 адреса, если мы хотим, допустим, попинговать такой IP-адрес, непонятно, сюда направлять такие пакеты или сюда.

Таблица маршрутизации ничего не даст, потому что таблица маршрутизации для этих IP-адресов вообще не работает. Поэтому, для того, чтобы указать зону действия этих адресов, приходится её через процент вот таким образом указывать, куда конкретно пакеты направлять. И еще один момент, который про эти адреса хотелось бы заметить. Формально говоря, весь блок FE80 по 10-й маске выдан под link-local адреса. Но есть нюанс. Этот нюанс заключается в том, что не любые адреса из этого блока вы по факту имеете право использовать. То есть, как все крокодилы зеленые, но, соответственно, крокодилы, они не только зеленые, они еще и, соответственно, с четырьмя лапками. Поэтому, если вдруг мы можем встретить что-то, что зеленое с тремя лапками или с шестью лапками, это не обязательно крокодил. Поэтому вот для всех link-local адресов выделена вот эта вот сеть FE80 по 10-й маске. Но, если вы хотите использовать link-local адрес по факту, вы обязаны использовать сеть

FE80 по 64-й маске. Это тяжелое наследие старых времен. Я призываю вас не заморачиваться на эту тему, просто запомнить, что-то по факту, да, что если вас будут спрашивать вот какой блок выделен под link-local адреса, говорит, что десятый. А какой по факту будет использоваться, тогда говорит 64-й. Если вдруг вам интересно, почему так, дело в том, что когда-то давным-давно были еще и сайт-local адреса, адреса, не маршрутизируемые за пределы вашего, называем это, сайта. То есть они такие промежуточные между link-local, которые не маршрутизируемые вообще, и unique-local, которые не маршрутизируемые, в интернете. То есть у них, допустим, внутри здания могли маршрутизироваться. И вот под эти сайт-local адреса был выделен диапазон, который был F... Сейчас вспомню. FEC0. И, соответственно, выглядит это все как... Вот давайте напишу FEC80. Это у нас 1111.

Дальше 1110. 1000. 0000. И десятая маска это вот так вот. То есть вот такие вот битики это link-local адреса. А FEC0 это другие адреса, которые сейчас считаются deprecated. Они имели очень похожий вид. 1111, 1110 и 1100. То есть это буквально следующая пачка адресов, которая идет за FEC80. И вот у этих самых FEC0 адресов был номер сайта, если хотите. И, соответственно, вот этот вот номер сайта записывался с 11 по 64 бита. То есть там вот адрес, вот большой такой адрес, состоял из правой части интерфейса ID. Дальше вот этого блока FEC0. Ну, FEC на самом деле. И дальше вот здесь вот записывался

subnet ID. Subnet ID. Вот. А для FEC80 адресов та же самая структура была предложена. Соответственно, здесь у нас ID-шник, здесь у нас FEC80, а вот здесь сказано было, ну, записываем нули. Для того, чтобы фактически одним стандартом одной RFC закрыть структуру и такого, и другого адреса. И поэтому было сказано, что вот сюда записывается subnet ID, для link local адресов вместо subnet ID пишется ноль, а дальше здесь вот как бы указатель на то, что это за адрес, здесь у нас интерфейс ID. А потом вот эту вот часть выпилилили. И осталась какая-то фигня, что у нас есть FEC80 по десятой маске, но все биты с 11 по 64 должны быть нулями. Поэтому просто запомните, что вот сейчас оно так и есть. Это просто тяжелое наследие древних времен, когда авторы протокола не знали, что может понадобиться и на всякий случай делали всякие разные вещи, которые потом не пригодились. Вот это вот

этот рудимент, который от первой версии протокола IPv6 остался, что FE80 по десятой маске. По факту только 64 маска может быть использована. Так. Далее. Если у вас есть какие-то IPv6 адреса, они могут быть совершенно произвольные. То есть, в принципе, вас никто не обязывает использовать ровно половину адреса под указание конкретного хоста в канале и оставшуюся половину под Network ID. Но некоторые механизмы, которые есть в IPv6, они будут очень сильно завязаны на то, что конкретный хост будет жить всегда в 64-й сети. Поэтому вот мы говорим, что интерфейс ID у нас обычно 64 бита. В принципе, он может быть любым. Вам никто не запрещает сказать, что у вас есть вот узел и он находится в канале, который давайте свитчек нарисую. И тут вот еще

раз компьютер и два компьютера. Ну, как-то они одновременно не рядышком друг с другом эти три компьютера у нас есть. И вот они все сидят на одном свитче, и вам никто не мешает сказать, давайте мы сделаем сеть ровно на четыре компьютера. И, соответственно, сделаем под них 126-ю или 125-ю сеть. То есть у нас будет там FD 00 2.1 слэш 125. Вот этот товарищ будет FD 00 2.2 слэш 125, 2.3 125. Но я, естественно, не пишу FD 00, меня просто лень писать. Ну, там 2.4 слэш 125. Вот вам никто не мешает вот такую штуку сделать. Гипотетически это допустимо стандартам, но если вы такое сделаете, если вы такие адреса ручками назначаете, то у вас некоторые механизмы,

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

может браться откуда угодно. Его единственная задача быть уникальным. То есть, он должен уникальным образом идентифицировать конкретный узел в пределах канала. Вот у нас есть 10 абонентов в сети, у каждого должен быть интерфейс ID отдельный, свой, не похожий на остальных. Можно сделать ручками этот самый интерфейс ID. Никто не мешает вам сказать, что у нас левый компьютер, 3 компьютера, 4 компьютера, и вот этому мы даем ID-шник FD00, и дальше говорим вот это 2.1, 2.2, 2.3, и 2.4. То есть, это все, вот эта вот правая часть, это интерфейс ID. Вот мы дали 4 подряд идущих интерфейс ID. Можем так сделать? Можем. То есть, идентификатор можно назначить ручками, можно назначить автоматически. Если это будет назначаться автоматически, то какие механизмы есть для придумывания правой части? Ну, правильный ответ любые. Как хотите, так и придумывайте. Но будет лучше,

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

и получить интерфейс ID. Самый простой адрес, который вы можете взять в качестве идентификатора, это MAC-адрес, он у вас в Ethernet есть? Есть. То есть если вы работаете поверх сети Ethernet, вы можете взять MAC-адрес, это адрес 48-битный, то есть там условно говоря с некоторой натяжкой 48-битной тропии, и он с вероятностью единицы будет уникальный в канале. Поэтому если вы его немножечко поменяете и сделаете его 64-битным, фактически разбавите водой в нужной пропорции, у вас получится уникальный интерфейс ID, и это как раз очень удобно для использования. Есть проблема, что не в любом канале MAC-е есть. То есть этот механизм, возьмите MAC-адрес и разбавьте его водой, он работает только там, где MAC-адреса работают. А есть канальные заряды, в которых MAC-адресов нету. Ну, тогда этот механизм там будет работать плохо. Можно для пущей уверенности, например, если вы не хотите, чтобы злоумышленник видел, что за MAC-адрес у вас используется,

взять хэш повторный от вашего вот этого самого того, что получилось, MAC-адреса разбавленного водой, и тогда обратное преобразование из IPv6-го адреса MAC-адрес уже сделать не получится. Ну, то есть возможных вариантов там куча. можно просто случайным образом придумать, сказать, ну, ничего страшного, что каждый раз при ребуте у нас будут новые MAC-адреса, новые IP-адреса. Ну, будут, ну и что? Вот. Ну, схему, которую надо будет знать на экзамене, она будет называться ModifiedEU64, и она как раз заключается в том, что вы берете MAC-адрес и делаете из него 64-битный идентификатор. Дальше. В чем заключается схема ModifiedEU64? У нас есть MAC-адрес, и мы должны из него сделать 64-битный интерфейс ID. То есть у нас MAC-адрес 48-битный, и, кстати, он придумывается по схеме EUI48, если вдруг вы помните. EUI48 — это схема, по которой генерируется MAC-адрес.

Это левая половина 24-бита OUI, Organizational UniqueIdentifier, и правая половина VendorAssignedID — это, соответственно, то, что Vendor назначает на заводе. То есть вот из MAC-адреса, который у нас здесь есть, левая половина будет называться OUI, а правая половина будет называться VendorAssignedID. Ну, строго говоря, VendorA, Assigned, дальше ID. Ну, я записываю, как вид. Довольно часто такая аббревиатура встречается. Так вот, как из 48-битного адреса сделать 64-й? Ну, берем, вставляем в середину 2 байта. Ну, не 2, а да, 2 байта. Вот эти вот характерные байты FFFE — это та самая вода, которую вы разбавляете MAC-адрес для того, чтобы у вас из 48-бит получилось 64. Но вот эта вот схема, когда вы берете MAC-адрес, делите его пополам и в серединку вставляете FFFE, она работает относительно неплохо, но она будет называться просто

EUI 64. То есть EUI 64. В IPv6 используется не EUI 64, а modified EUI 64. И вот разница между обычной EUI 64 и modified EUI 64 заключается в одном битике. EUI 64. Если вы взяли MAC-адрес, распилили его пополам, ставили FFFE в серединку, вы для получения modified EUI 64 должны будете почти самый младший битик первого байта флипнуть. То есть у вас этот MAC-адрес, который был, этот почти самый младший бит первого байта, он отвечал за то, как сгенерирован этот MAC, сделан ли он на заводе по схеме EUI 48, или его администратор придумал своей волей какой-то произвольный и красивый. И вот, соответственно, для modified EUI 64 вы этот битик должны перевернуть. Если там был единица, сделать ноль, а если там был ноль, сделать единицу. И вы не поверите, вы никогда не догадаетесь,

если не знаете, зачем это сделано. Это сделано для красоты. Вот, я не шучу. В стандарте так и написано, что это мы делаем для красоты. И если вам кажется, что это какая-то наркомания, и кому в голову пришло для красоты чего-то там флипать, обоснование будет следующее. Если у вас есть MAC-адрес, который прошит на заводе, он некрасивый. Ну, он по определению случайный, поэтому с очень большой вероятностью он некрасивый. И если вы не заботитесь о том, какой у вас MAC-адрес, вы вставляете в серединку FFFE, у вас получается некрасивый случайный идентификатор EUI 48, в смысле EUI 64, он уже некрасивый. И вы, что бы с ним ни делали, какие битики бы вы не флипали, она так останется некрасивым. Поэтому из некрасивого MAC-а у вас получается некрасивый, но зато случайный адрес. Но, если вы в свое время взяли MAC-адрес красивый, то есть вы его ручками переопределили, и у вас получился адрес, который действительно хороший, удобный,

но вот у него по определению в этой ситуации в почти самом младшем бите первого байта должна стоять езничка. То есть вы должны поднять этот самый битик, почти самый младший бит первого байта, для того, чтобы показать, что этот адрес локально уникальный. Не вселенский уникальный, а локальный. Вот этот вот почти самый младший бит называется u-slash-l universe или local. Универсально вселенский уникальный адрес или локально уникальный адрес. Универсально или вселенский уникальный, это значит, что за уникальностью этого MAC-а следит IEEE. А, соответственно, если администратор говорит, я переопределяю действия Международного Союза радиоэлектронных компаний инженеров и, соответственно, я делаю MAC-адрес по какой-то своей воле, я понимаю, что кто-то другой может придумать такой же MAC-адрес, но я в любом случае не буду с ним пересекаться, потому что и за свою сеть я, соответственно, отвечаю, и я понимаю,

что этот адрес сделал именно я, именно для своей сети, и сделал я его, скорее всего, красивый. Вряд ли вы будете делать случайный MAC-адрес, если вы его переопределяете. Вы его, скорее всего, сделаете красивым. И вот пример. Гипотетически, может ли такое быть, что у железки будет MAC-адрес 00000000001? Вот такой вот красивый MAC. Может быть? Может. Это MAC-адрес, если мы посмотрим, он, соответственно, состоит из OOE все нули, и дальше vendor-asside.id вот такой вот, единичка. Этот MAC-адрес сделан на заводе. На это нам намекает нолик в почти самом младшем бите первого байта, как я про это узнал, потому что самый первый байт состоит целиком из нулей, поэтому он точно заводской. Если я хочу сделать такой же красивый MAC-адрес, могу ли я это сделать? Могу. То есть, вот этот вот MAC-адрес я точно не могу сделать. То есть, он заведомо прошит на заводе, если вдруг вам интересно, это Xerox. Он же Xerox. То есть,

могу ли я получить такой MAC-адрес в сети? Могу. Я должен для этого пойти в магазин, купить железку Xerox и с очень маленькой вероятностью, но гипотетически такое может быть, что у нее MAC-адрес окажется вот такой. Но я ее не выбирал, как бы такую железку с таким MAC-адресом, она у меня случайно получилась, и дальше из нее получился какой-то там, простите, какой-то там IP-шник. Но, если я хочу умышленно сделать такой вот красивый MAC-адрес, вот именно такой я сделать не могу, но я могу сделать MAC-адрес 0, ой, простите, 0200000000001. И вот такой вот MAC-адрес означает, что этот MAC-адрес уже не сделан на заводе, у него самый младший битик, почти самый младший битик первого байта, он флипнут. И, соответственно, он состоит из вот этого битика, который указывает на то, что администратор его переопределил, и дальше каких-то красивых всех остальных битиков. Вот. Что получается в итоге? После того,

как мы вот этот вот битик флипнули, у нас получился достаточно красивый MAC-адрес, но у него вот этот вот битик, который выставлен в единицу, он некрасивый, он мешает нам жить, и он нам портит всю красоту. Если мы из вот этого вот MAC-адреса сделаем IPv6 интерфейс ID, у нас получится по схеме обычной EOE64, 0200, дальше 0000, 0, сейчас, простите, нет, не так получится. Мы разбавляем это FFFE. 0, F, F, F, E, 00, 00, 01. Вот такой вот интерфейс ID получится из такого вот MAC-а. И если мы его сократим по нашим нормальным правилам, получится 00, FF, F, E, 00, двоеточие, единица. Из, в общем-то, красивого MAC-а, ну, пусть не самого красивого, но все-таки красивого,

у нас получился какой-то кривой, косой интерфейс ID. В то же время, если мы пользуемся Modified, EOE64, мы обратно флипаем тот самый битик у красивого MAC-а, и у нас получается интерфейс ID 0000, 0, F, F, E. Дальше. Так, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0. Запутался. Так, простите. Давайте с нуля запишу. так 0 0 0 0 0 0 0 f f e 0 0 0 0 0 1 вот такой вот и соответственно он сокращается до просто 0 2 . f f 2 . f e 0 0 2 . 1 вот это вот чуть более красивая штука чем вот это соответственно уны и если придумали mac адрес вручную то обратное преобразование вот это вот бить как оно соответственно позволяет нам

получить чуть более красивые пивы 6 адреса схема абсолютно на мой взгляд дурацкая но тем не не менее, вот авторы протокола ее такой придумали. Поэтому, как выглядит обычная EO64? Вставляем в серединку FFFE. Как выглядит модифай от EO64? Флипаем дополнительно почти самый младший битик первого байта. Что значит флипаем? Если там был нолик, то есть MAC-адрес изначально был заводской и случайный, делаем из него единичку, и IPv6 интерфейс ID тоже получается уникальный и какой-то случайный. Если же там была единичка, то мы получаем ноль. Таким образом, у нас получается однозначное преобразование MAC-адреса в интерфейс ID. Как из интерфейса ID и имеющейся левой части получить IPv6-ой адрес? Ну, просто взять и склеить их. То есть, вот представим себе, что у нас есть вот такой вот MAC-адрес. 7.8.8.4.3.C.E.B. 4.F.C.7. Как получить из него EO64?

Вставить в серединку FFFE. Дальше. Как получить модифайл от EO64? Флипнуть почти самый младший битик первого байта. Вот это MAC-адрес заводской. Как я это узнал? Потому что восьмерка — это 1.0.0.0. То есть, у него почти самый младший битик — это 0. Вот если я его флипну, получится 1.0.1.0. Это эквивалентно прибавлению двойки. К восьмерке прибавить двойку будет 7A. Соответственно, 7A.8.4.3.C. FFFE.E.B. FC7. Вот это вот модифайл от EO64, интерфейс ID, полученный из MAC-адреса. Дальше нам говорят, в каком конкретно канале у нас используется какая сетка. Если нам ничего не говорят, мы хотим сами себе придумать адрес link-local-unicast. Прекрасно. F-E80. Приклеиваем к нему вот эту вот колбасу и получаем link-local-адрес. Если нам говорят, в этом же канале, на этом же интерфейсе придумай себе global-unicast-адрес, и каким-то образом говорят, вот тебе сетка, в которой надо это придумать. Окей, не проблема.

Берем эту сетку и приклеиваем к ней справа вот это вот. И у нас получается полноценный IPv6-й global-unicast-адрес. Да, случайный, да, некрасивый. Так он сгенерился только что. Как бы мы... Почему мы вдруг будем требовать, чтобы он был красивый? Просят от нас, не знаю, unique-local-unicast, и дают нам вот такую вот сетку. Ну, то есть это... Депликейт, это вообще-то говоря адреса, но тем не менее. Дают ее и говорят, возьми вот такую сеть и придумай себе в ней IP-шник. Никаких проблем. Берем то, что нам дают, приклеиваем к ней вот то, что справа. То есть в любом случае все адреса, которые у вас будут генериться по схеме интерфейса ID, Modified E64 или какой-то другой, будут иметь одинаковый. У них будет различаться только левая часть в подавляющем большинстве случаев. Может ли быть такое, что у нас будут разные IP-шники с разными хвостами? Конечно, могут. Никто нам не мешает придумать помимо такого интерфейса ID еще десяток других. Просто часто будет встречаться именно такая ситуация, что на одном и том же интерфейсе

все IP-шники у нас будут заканчиваться на один и тот же интерфейс ID. Зачем плодить больше, если этого делать не нужно, незачем. В этом случае, если не просят, не будем плодить. А если просят, никто нам не мешает на этом же интерфейсе взять и повесить IP-шник 2001:db8:b16b:b5::1. Можно сделать такое? Можем. На экзамене будет вопрос, вам дают либо MAC-адрес, говорят, придумайте из него IPv6 интерфейс ID по Modified EUI-64, либо наоборот. Говорят, вот вам IP-шник, он придуман по EUI-64, какой был MAC-адрес. Прямое преобразование я вам показал на предыдущем слайде. Берем MAC-адрес, делим пополам, вставляем в середину FF:FE, они разъезжаются по шестому и седьмому октету при этом, кстати. И дальше флиппим битик. Либо, если вам дают обратную задачу, говорят, вот IP-шник, какой был MAC-адрес.

Опять же, смотрим на то, что в серединке между шестым и седьмым октетом есть FF:FE, собираем эти две кучки воедино и, опять же, флиппим почти самый младший битик первого байта. Та же самая операция. У нас получается MAC-адрес. По сути, данная генерация интерфейса ID сделана исключительно для удобства, потому что, с другой стороны, получается проблема с безопасностью. У Modified EUI-64 есть очень большой плюс, который заключается в том, что она простая, как барабан. Она предсказуемо работает и работает понятным образом. Но проблема с безопасностью действительно у нее есть, потому что вы тем самым, если показываете, что у вас есть определенный IP-шник, вы подключаетесь к условному серверу Google.com, вы показываете свой IP-адрес, вы неизбежно его декларируете в любом IP-пакете, который вы отправляете. У вас показывается, что вы отправили пакет из-под определенного адреса. И если вы в своем IP-шнике показываете, что у вас есть это FF:FE, вы гипотетическому атакующему,

который такие пакеты может перехватить, равно как и конечному получателю таких пакетов, условному Google.com, фактически даете указание: я придумал адрес по механизму EUI-64, Modified EUI-64. Он может из этого механизма сказать, давайте посчитаем, какой у вас MAC был. Он берет, соответственно, две эти части, склеивает между собой, флипает битик и говорит: ага, MAC-адрес, похоже, был вот такой. 78, 84, 30, чего-то там. Что дает атакующему MAC-адрес? Понятное дело, что напрямую ничего не дает, но в нем содержится определенная информация, которая гипотетически может быть использована для каких-то задач. Например, он может взять и сказать: вот этот OUI — это OUI, не знаю, компании Dell, или Sony, или Cisco. И по этому OUI можно уже сделать вывод, что это за железка. Можно гипотетически предположить, что, раз вы пользуетесь для отправки данных IP-шником, сделанным по MAC-у

компании Cisco, то, наверное, сама железка тоже цисковская. Наверное, можно предположить, что там используется операционная система Cisco, и можно, исходя из этого, сделать какие-то далеко идущие выводы. Не то чтобы прямо уж очень страшно то, что вы тем самым показываете, какой у вас MAC-адрес. Все равно до этого MAC-адреса еще стучаться надо. Но все равно вы немножко атакующему информации про себя раскрываете. Поэтому, например, операционная система Windows эту схему по умолчанию не использует. Она вместо нее использует как раз хэш от MAC-адреса. Она сначала делает Modified EUI-64, а потом берет от него хэш. И тогда получается, что вы сам MAC-адрес не показываете. Да, механизм у вас работает, когда вы взяли MAC-адрес, сделали из него IP-шник, и вы это всегда будете делать предсказуемо, повторяемо. И даже если вдруг вы нигде не сохранили конфигурацию того, как у вас что-то получалось на предыдущем шаге, все равно в следующий раз у вас будет на основе того же самого MAC-адреса по тому же самому алгоритму

получаться точно такой же результат. Но при этом Windows не раскрывает свой MAC-адрес изначально. Cisco, например, не стесняется говорить, что она Cisco, и она использует Modified EUI-64. Тот же самый MikroTik тоже не стесняется, раскрывает. Вообще, сетевые железки, как правило, используют Modified EUI-64 без особых проблем. Про мультикаст. Мультикастовые адреса в IPv4 используют диапазон класса D, они начинаются на битовые 1110. 1110, простите. Четыре первых бита у них зафиксированы. В IPv6 под мультикаст выделен диапазон FF00::/8. Это адреса, начинающиеся на 16 первых единиц. Любой адрес, начинающийся на FF — это мультикастовый адрес. Когда вы отправляете какой-то пакет в канале,

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

При этом у вас есть на хостах какой-то механизм определения, интересен ли определенный трафик будет или нет. Например, если у нас есть четыре узла в сети, один узел хочет отправить какой-то пакет так, чтобы C и D не зажмурились, а B зажмурился. Почему он может отправить такой пакет? Потому что на самом деле у нас есть какая-то приложенька, и у нас есть, не знаю, первый канал, телевизор. У нас есть мультикастовый источник. Мы хотим отправить один пакет так, чтобы он дошел до двух получателей, до третьего — может, дошел, может, не дошел бы. Нам не сильно интересно, что там произойдет. Мы не хотим отдельно отправлять C-шке копию данных и отдельно отправлять D-шке копию данных. Мы хотим один пакет отправить, чтобы он дошел до обоих сразу. И как C-шка определяет, что данные ей интересны? Она запускает у себя, соответственно, приложеньку, которая слушает первый канал. И, соответственно, эта приложенька сама говорит, что вот такой IP-шник надо слушать.

То же самое узел D. Он запускает у себя приложеньку, которая слушает первый канал. Телевизионный, да? Он тоже слушает определённые пакеты. А B-шка у себя не запустила первый канал. Она запустила, не знаю, второй канал. В этом случае она не слушает пакеты, которые идут на мультикаст в адрес соответствующей группы первого канала. Так. Как эта штука будет выглядеть? Любые адреса, которые в IPv6 мультикастовые, начинаются на FF. Дальше есть четыре специальных битика для флагов, потому что мультикаст в IPv6 бывает очень сильно разный. И прямо в самом адресе можно написать, какой это мультикастовый адрес. Нас сейчас не сильно интересует, что там за флаги есть. К CCI будете готовиться — там разберётесь. Дальше четыре битика области видимости мультикастового адреса, то есть область, в пределах которой он может распространяться. Мы с вами говорили, что в принципе бывает маршрутизируемый мультикаст и немаршрутизируемый мультикаст. В рамках нашего курса наши интересы ограничиваются немаршрутизируемым мультикастом.

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

У нас есть адреса, начинающиеся в IPv4 на 127. Всё, что мы пытаемся отправить на такой IP-шник, оно никуда не отправляется, нам не нужно это отправлять. Оно само приходит на стек IP, как будто бы мы только что получили пакет на каком-то интерфейсе, в котором пришло определённое содержимое. В IPv4 у нас для лупбеков была большая-большая сетка, 127.0.0.0 по восьмой маске. В ней аж 16 миллионов адресов. В некоторых ситуациях удобно то, что вы можете из этой сети нарезать себе много IP-шников, которые все принадлежат именно вам. Вы можете сказать, что у вас какое-то взаимодействие идёт по 127.0.0.1, какое-то взаимодействие идёт по 127.0.0.2, потом 0.0.3. Это всё происходит в пределах вашего компьютера. Вы на эти адреса отправляете данные, и они приходят именно вам. В некоторых ситуациях некоторым приложениям это будет удобно. Мультикаст, который будет работать в пределах рабочей станции, это по сути та же самая штука.

Вы говорите, что у нас есть желание отправить самим себе мультикастовый пакет. Понятное дело, что все, кто его получит, — это мы и есть. И этих адресов вы можете наплодить сильно больше, чем /8 сетка с 16 миллионами в IPv4. Иногда возникает вопрос: как же так? Лупбеков в IPv4 было 16 миллионов, а в IPv6 он всего один — ::1. Всего один такой адрес, это лупбек в IPv6. На самом деле этот адрес есть как основной адрес лупбека, но есть ещё огромное количество мультикастовых адресов, которые вы можете сами себе напридумывать. Их намного больше, чем 16 миллионов в этой сети. Мы опять же не будем никогда с этим работать, с этим пусть программисты работают, а двоечка — это немаршрутизируемый мультикаст, который мы как раз будем довольно часто видеть. FF02 — это как раз немаршрутизируемый мультикаст,

который можно отправить в пределах провода. Область видимости у такого немаршрутизируемого мультикаста — это канал. Все, кто находится в одном канале с нами, такой мультикаст получат. Но через роутер он уже не пройдёт. Можно встретить другие возможные варианты этого разряда, который здесь двоечка стоит. Если там будет стоять четвёрка, пятёрка или восьмёрка — это маршрутизация в определённых границах в пределах вашей организации. Можно сказать: в пределах вашего здания маршрутизируемый мультикаст, в пределах вашей страны маршрутизируемый мультикаст, или в пределах вашего континента, или в пределах вообще вашей организации, но не выходя наружу в интернет. Если на E будет заканчиваться первая группа, то это маршрутизируемый в интернете мультикаст. Тот, который, я говорил, уже не пригодился, потому что маршрутизируемого мультикаста в интернете нет. Но под него закос был. Мы будем работать с тем мультикастом, который заканчивается на двоечку. FF02 — это немаршрутизируемый мультикаст, он нам и будет нужен.

Дальше для самого идентификатора группы, для того чтобы сказать, что это за группа, чем отличается первый канал от второго, от третьего, от четвёртого, у нас есть аж 112 битов. Это много. Какие адреса нас будут интересовать? Те, которые начинаются на FF02. Никакие другие адреса в рамках нашего курса мы смотреть не будем. Полезные адреса, которые имеет смысл запомнить. FF02::1 — это то же самое, что в IPv4 было 224.0.0.1. Но есть нюанс. 224.0.0.1 — это в IPv4 адрес «вообще все», но по сути своей — все, кто поддерживает мультикаст. Потому что бывают узлы, которые в IPv4 существуют, но мультикаст не поддерживают. Они слишком старые. Они были изобретены до того, как был придуман мультикаст в IPv4. Потому что изначально его там не было. Он был пристёгнут отдельно. Сначала его называли IPv5, потом он появился в составе IPv4 как дополнительный механизм.

224.0.0.1 — это вообще все, кто поддерживает мультикаст. В IPv6 есть мультикастовая группа «вообще все». FF02::1. Не может быть такого, что узел в IPv6 не поддерживает мультикаст. Все поддерживают мультикаст. Понятное дело, что это взаимодействие — фактически то же самое, что бродкаст. Вы отправляете какой-то кадр, IP-пакет, и он доходит до всех узлов в канале. Поэтому классическое утверждение заключается в том, что бродкаста в IPv6 нет. Но более правильное, более корректное утверждение заключается в том, что бродкаст — это частный случай мультикаста. И поэтому группа FF02::1 — это тот самый бродкаст, которого в IPv6 нет. Просто переименовали милицию в полицию. FF02::2 — это аналог 224.0.0.2. Это группа «все роутеры», но в IPv4 — все роутеры, которые поддерживают мультикаст, а в IPv6 — это просто все роутеры.

И ещё один адрес, который нам понадобится, это даже не один адрес, это шаблон, по которому строятся адреса. Запомните это страшное название — SNMA, Solicited Node Multicast Address. Это все узлы с IPv6-адресами, у которых есть определённый хвост. Если у нас есть SNMA, такой страшный, FF02::1:FF28:9C5A, это все IPv6-узлы, которые заканчиваются на 28:9C5A. Потом, когда будем говорить про обнаружение соседей, я вам расскажу, зачем эта штука нужна. И вы, если у меня получится рассказать, поймёте, что это совершенно гениальная вещь. Может показаться, что какая-то страшная на данный момент, но на самом деле ничего страшного нет. Это красивейшая идея, которую совершенно гениальным образом реализовали авторы протокола. Я считаю, что за эту штуку надо дать памятник.

Так. Ещё одна вещь, про которую говорят, что в IPv6 она появилась, хотя в IPv4 её не было, что на самом деле правдой не является, потому что в IPv4 она была, — это Anycast-овое взаимодействие. Есть Unicast, есть Broadcast, есть Multicast, есть Anycast. Так же как Broadcast — это частный случай Multicast, Unicast — это частный случай Anycast. Anycast — это более широкое явление. Смысл Anycast заключается в том, что у вас есть несколько узлов, у которых имеется одинаковый IP-шник. Вы можете отправлять некий пакет до указанного IP-шника, и он будет приходить на один какой-то узел, у которого такой IP-шник есть. Но ровно на один. Это не Multicast и даже не похоже на Multicast, потому что в Multicast вы отправляете один пакет, и он доходит до всех сразу. А здесь вы отправляете один пакет, и он доходит ровно до одного. Но, как правило, доходит до ближайшего обладателя определённого IP-шника. У нас есть узел B вот этот и B вот этот.

У них одинаковые IP-адреса. Но сама сеть принимает решение, как доставить трафик до одного из этих узлов, и она направляет этот трафик от узла A именно до нижнего узла B, у которого есть определённый IP-шник. Она не отправляет этот пакет наружу, наверх. В то же время, если у нас здесь будет какой-то узел, который будет пытаться с этим же узлом B вести взаимодействие, он пойдёт по своей более короткой трассе. Зачем эта штука нужна и почему мы про неё специально говорим? Дело в том, что это очень удобный механизм обеспечения отказоустойчивости и распределения нагрузки. Если у вас узел B, например, выключается, что-то с ним происходит, ближайшим узлом B к левому узлу A будет как раз наш единственный узел, и трафик пойдёт на него. Поэтому всякие штуки, связанные с распределением нагрузки, балансировкой и прочим, эту вещь очень любят. Из того, что вы ежедневно используете, механизмы, которые используют Anycast, — это, например, DNS.

DNS очень часто распределяется как раз с помощью Anycast. Корневые серверы, которые обеспечивают всю инфраструктуру DNS, они почти все Anycast. Зачастую организации используют Anycast-взаимодействие для того, чтобы распределить нагрузку по разным зонам. Например, я знаю, что Сбербанк использует эту штуку, потому что у Сбербанка есть такая вещь, как Сбербанк Онлайн. Как вы понимаете, нагрузка на серверы Сбербанка Онлайн колоссальная, потому что все 100 миллионов взрослых пользователей России так или иначе Сбербанком Онлайн иногда хотя бы пользуются. Поэтому нагрузка на точки приземления трафика, эти самые сбербанковские, она, конечно, очень большая. Для того чтобы обеспечить отказоустойчивость, для того чтобы обеспечить какую-то разумную нагрузку на один сервер, этих серверов на самом деле много. Это не какой-то один сервер, на котором крутится тот самый Сбербанк Онлайн. Это много разных серверов. И когда вы пользуетесь Сбербанком Онлайн, вы пользуетесь именно ближайшим к себе, который находится, скорее всего, даже в вашем регионе.

Это, ещё раз подчеркну, удобная вещь, очень часто используемая. Фактически мы можем сказать, что Unicast — это взаимодействие, когда у нас есть один узел, который обладает определённым уникальным IP-шником. Это частный случай Anycast. Anycast позволяет нам один адрес распределить по нескольким узлам, и трафик идёт до ближайшего. Unicast — это всё то же самое, только группа Anycast у нас всегда состоит из одного узла. Как-то так. В порядке бреда. На интерфейсе в IPv6 у вас может быть, и чаще всего бывает, много адресов, может быть такое, что они будут получены разными способами. Как минимум у вас настроится link-local адрес на интерфейсе, на котором есть IPv6, всегда. Вы можете определить, что у вас есть какой-то интерфейс с включённым IPv6, и у вас там всегда будет адрес, начинающийся на FE80. Это не означает, что вас похакали и кто-то вам повесил какой-то IP-шник. Он всегда там есть. У вас может быть адрес,

который вручную был настроен. У вас может быть адрес, который вы получили автоматически от соседей. Вам соседи рассказали, какие адреса использовать. У вас может быть тот же самый DHCP. Этих механизмов настройки адресов на самом деле много. И каждый адрес, который вы получаете, он имеет некий жизненный цикл. Если это динамические адреса особенно, то они не бесконечны. Они так же, как в DHCP, выдаются на некоторое время. В IPv6 практически любой адрес действует в течение некоторого времени. Если вы автоматически от соседа получили указание, что у вас в сети используются некоторые адреса, то вы получаете эти адреса, вы их начинаете использовать, но вам через некоторое время соседи должны подтвердить, что эти адреса всё ещё используются, и тогда вы сможете их использовать. Так, да, вопрос поступил. Используются ли для Anycast какие-то специальные адреса? Нет, используются обычно те адреса, которые мы называем Unicast.

Если говорить про IPv4, в IPv4, давайте вернусь на предыдущий слайд, для Anycast был выделен диапазон 192.88.99.0/24. Это публичные адреса, видите, публичный IP-шник, но он был специально выделен для Anycast. Но по факту из этого диапазона штатно выделен адрес 192.88.99.1. Этот адрес используется для хорошо известной службы 6to4. Но есть огромное количество Anycast-адресов, которые никак себя не афишируют, вы никогда по внешнему виду этого IP-шника не скажете, что он Anycast. По сути своей может быть такое, что у вас есть, в кавычках, Anycast-группа, только в этой группе всего один узел. Это вообще никак не отличить от нормального Unicast-взаимодействия.

А вот, кстати, хороший пример. 8.8.8.8. Это же тоже не один какой-то узел, не один какой-то сервер, который стоит где-то там в каморке у кого-то под столом на работе в Гугле. Это большое количество серверов, которые стоят абсолютно в разных зонах, в разных местах. Вы имеете один и тот же IP-шник, но, соответственно, приземляетесь каждый раз на разный сервер. Это Unicast-овый IP-шник, по большому счёту, но по факту этот Unicast-овый IP-шник принадлежит большому количеству узлов. И трафик, когда мы его направляем, идёт на ближайший. Та же самая история в IPv6. Используются те же самые публичные IP-адреса или частные IP-адреса, которые у вас есть. Они по внешнему виду не отличаются от нормальных адресов, но при этом просто этот адрес принадлежит двум разным хостам, и сама сеть решает, на какой из хостов прямо сейчас отправить трафик. Поэтому Anycast визуально от Unicast не отличается. Он только по смыслу отличается.

На этом, пожалуй, хватит говорить про теорию IPv6. Давайте поговорим немножко про его заголовок и попробуем что-нибудь сделать на практике. Спасибо.