Излом

Про IPv6
Пара слов про мое отношение к IPV6 после попыток внедрить его в бизнесе среднего размера:

* У нас теперь 128 бит на адрес. Да адреса не читаемые, не запоминаемые, а сокращение 0000 через "::" местами еще больше запутывает, но ок. Все ради этого и задумывалось.
* У нас теперь более простой заголовок пакета стабильной длинный и нормальные extended заголовки вместо непонятных опций. Это ок, надо было с самого начала так. Наконец-то заголовок IPSec нашел свое место в ~~жизни~~ пакете.
* Убрали фрагментация. Тоже ок, больше не надо мучиться с подстройкой MTU в VPN каналах.
* Ну не совсем убрали, ей теперь занимается отправитель/получатель. Но им еще надо сообщить максимальный MTU по ICMPv6.
* Убрали контрольную сумму IP. Конечно уже не начало 90х, когда маршрутизаторы были медленные, но ничего плохого в этом нет. Хотя теперь в UDP и других транспортных протоколах контрольная сумма обязана быть. Если не прямым текстом это говорится, то подразумевается точно.
* Переименовали несколько полей в заголовке и дали им немного другие значения. Ок, жить можно.
* Добавили flow label. Тоже гуд, conntrack будет лучше работать. (Шутка про NAT для любых транспортных протоколов).
* Джамбофреймы до 4Gb! Ну учитывая, что маршрутизатор не должен будет резать их на пакетики по 1500 byte при выходе их jumbo-сегмента тоже можно попробовать.
* Определились с форматом Traffic Class. Точно определились? Точно-точно? Ну посмотрим.
* Придумали как использовать "маршрутизацию от отправителя" для мобильного роуминга. Ну это надо на практике посмотреть, но идея интересная.
* Несколько IP на один интерфейс. Нет, это круто но на практике конечным пользователям практически никогда не нужно. Может не будем развивать эти идею для массового потребителя. когда это не нужно. Нет? Будем? Ладно...посмотрим что получится...
* Больше нет broadcast. Ну за 30 лет с IPv4 мы уже привыкли и научились делать L2 устойчивыми к broadcast storm, но IPv6 ведь не дураки делают, раз сказали что нет broadcast, значит нет.
* Без ICMPv6 больше жить нельзя. Просто смиримся и прекратим параноидально блокировать.
* Anycast всем и каждому. Тут как с роумингом, пока на практике не увижу не могу оценить, но звучит годно.
* Multicast всем и каждому. Ну мы отказались от broadcast в пользу multicast...Не ну в целом круто, теперь я могу отбрасывать пакеты предназначенные не мне на L2/L3, снижая нагрузку.
* А еще теперь несколько зон видимости multicast. Ну ничего что на практике будет глобального-мирового multicast у нас скорее всего никогда не будет ибо его будут жестко резать провайдеры. Но технически это возможно.
* Для замены Broadcast на Multicast нам нужен адрес на интерфейсе, давайте добавим Link Local. Так ну ок, мне эта идея не особо нравится, но если оно будет использоваться только для согласования нормального адреса на начальных этапах, то ок...
* А нет, LL адрес висит на интерфейсе всегда. Ну ладно будем жить с этим.
* Вместо ARP теперь ND, ну ок.
* Теперь у нас целых два способа автоматически раздавать адреса в локальную сеть: SLAAC и DHCPv6. Эм...ну ок, наверное, хотя dhcp не особо проблемный сервис, а для SLAAC как и для dhcp нужно запускать отдельные демон рассылающий ra...
* Ага, для dhcp по хорошему теперь тоже надо запускать демон рассылающий ra, дабы dhcp-клиенты не слали лишнего в multicast...эм ну ок.
* Для "конечных" локальных сетей у нас теперь префикс /64 и SLAAC работает только с ним. Гм, как-бы эта история не обломалась как классовая адресация на заре IPv4, но тут хоть починить не сложно будет.
* Для SLAAC мы будет генерировать IP на базе MAC адреса. Ой это-же создает проблемы, когда по второй части IP можно идентифицировать устройство в разных подсетях.
* Ладно, у нас адресов много давайте тогда каждый раз генерировать новый рандомный IPv6. А может генерировать новый спустя некоторое время? А может по новому на каждое соединение, у нас же можно много адресов на интерфейсе иметь!
* Ну окей, а как мне теперь к соседям по сети коннектиться, когда у них длинные, нечитаемые адреса еще и генерирующиеся рандомно. DNS - не, они-же рандомные! А ну вот есть пара костылей для автоматического поиска соседей и генерации dns имен, только эти костыли не совместимы между собой и поддерживаются не всеми хостами.
* Ладно, понял ваш SLAAC. Мне нужно что-бы у хостов были статичные адреса, которые я могу использовать в firewall и pbr. У нас есть DHCPv6.
* В смысле DHCPv6 не сообщает клиентам default route? А что тогда? А ну да...Link Local адрес роутера...А ну давайте еще адреса с маской /128 отдавать, мы-же так хотели снизить нагрузку на маршрутизатор, а клиенты из одной подсети должны между собой по Link Local общаться, обнаруживая друг-друга через несовместимые костыли. Я уже говорил, что идея использовать Link Local для чего угодно кроме изначально идентификации показалась мне плохой изначально?
* А еще провайдер теперь должен раздавать нам префиксы. Если подсеть за роутером одно - /64, если много - /56. И как-бы не важно, что большая часть выданного адресного пространства не будет использоваться у нас же 2^128 адресов! А потомки разберутся.
* DHCPv6 больше не привязан к броадкасту и его можно навешивать на ppp интерфейсы. Для получения префиксов по PPPoE/L2tp/пр. Ура!
* Всмысле isc-dhcp-client не умеет биндиться на pppoe? Ну ок, что у нас там есть еще в репозитории?
* Всмысле isc-dhcp-server не умеет создавать маршруты для розданных префиксов автоматом? Что у нас там еще есть в репозитории...а оно все тоже не умеет...ладно, пойдем выпрашивать бабло на cisco/juniper.
* Всмысле, клиент (роутер) получивший префикс может по воле левой пятки выбрать в качестве адреса отправителя один из трех: link lical/от dhcp/от slaac. И default route тоже будет разный. Разброд и шатание.
* Хотя зачем тратить кучу бабла у нас-же есть Mikrotik, они ведь умеют IPv6, даже официальный курс выпустили...умеют, да...ну если вся сеть (включая провайдера) на Mikrotik, то все будет хорошо, иначе придется статикой настраивать...местами.
* Короче пока с dhcp для раздачи адресов все не придет в норму надо быть готовым конфигурировать статику. XXI век, IPv6, интерпрайз, статика...
* Теперь у нас полная IP связанность и можно не настраивать параноидельный firewall на роутере, теперь надо настраивать параноидальный firewall на клиентах...и не важно,что клиентами может быть шиндофс иди ведроид.
* Больше нет NAT. Ну технически теперь у нас есть NAT6to4/NAT4to6 для совместимости, но это головная боль провайдеров и NAT6to6 (у ряда вендеров), а еще есть странная штука NPTv6 с неясным юзкейсом, но всем будем говорить что NAT нет.
* А ничего что NAT мы использовали еще и как анонимизатор для миксования трафика с другими людьми? Да это частый юзкейс, особенно в россии, где бизнес честно вести не принято.
* По задумке VPN провайдеры теперь тоже выдают по /64 подсети...и вот сидит ваш клиент, у которого по SLAAC/DHCPv6 настроено два IPv6 (от провайдера и от vpn) и только OS ведомо, как там будет ходить трафик.
* А профит? Ну для бизнеса с небольшой сетью он есть. Больше не нужно делать VPN каналы между офисами и настраивать динамический роутинг, можно положиться на "прозрачны" IPSec на офисных маршрутизаторах и маршрутизацию провайдеров, но если сеть будет разрастаться, то придется возвращать OSPFv3. Но это при условии, что во всех офисах провайдеры предоставляют IPv6. Ну и возможно для "домашних" подключений надо будет стоить 6in4inIPSec туннели. Для выхода в мир смысла нет никакого, большинство "рабочих" сайтов и ресурсов доступны только по IPv4.

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