Поддержка NPTv6 / RFC 6296?

Какие новости по этому вопросу? Похоже, ядро Linux 3.13 уже имеет встроенную поддержку NPTv6.

NPTv6 — это не "NAT", как ты подразумеваешь, это означало бы «государственная трансляция адреса/порта». NPTv6 этого не делает, он просто выполняет безсостоятельную трансляцию префикса. В отличие от NATv4, который как-то просто «возник», с различными несовместимостями в реализации, NPTv6 очень чётко специфицирован в RFC. Чтобы быть ясным, я абсолютно не вижу смысла в развёртывании IPv6 без NPTv6: Идея "каждый, кому нужен статический адрес, просто должен получить PI и чтобы его ISP маршрутизировал его" уже провалилась. Ни один ISP (по крайней мере, в Германии) не будет маршрутизировать твоё PI пространство, если ты не готов платить несколько тысяч евро в месяц. И даже тогда: В наши дни каждый BGP пир будет отбрасывать IPv4 маршруты меньше /24. Скорее всего, мы увидим аналогичное развитие для IPv6. Никакой бизнес не подпишется на безумную идею "просто автоматически настроить всё". Это означало бы, что нам нужна DNS инфраструктура для поддержки этого, а это означает DNSSEC - который, скажем так, тонет. Также это означало бы наличие коммутаторов с RA guard и т.д. в каждом углу сети, что вряд ли произойдёт в ближайшее время. Лично я не заинтересован в том, чтобы все устройства в моей домашней сети меняли свой префикс каждые 24 часа - потому что, да, даже с IPv6, домашний интернет-доступ в Германии всё равно даст тебе только динамичный префикс, если ты не готов выложить вдвое больше денег за бизнес-контракт. Поскольку PI — это но-го для многих SMB, им придётся идти на PA пространство — а это значит, что они будут привязаны к одному ISP, если не захотят менять всё в своей внутренней сети (или… DNSSEC), что обычно требует гораздо больше работы и стоит гораздо дороже. Моё предложение довольно простое: Получи некоторое PI пространство от члена RIPE, который зарегистрирует его для тебя дёшево, используй это PI пространство внутри своей сети, чтобы быть независимым, и NPTv6 для трансляции его в пространство, выделенное ISP (или в пространства, если мы говорим о DSL+ UMTS резервировании).

Не делай этого. Делай это правильно, а не как халтурщик. Я не уверен, какие там реальные затраты, но пара тысяч евро в месяц — это довольно дороговато, чтобы просто объявить префикс. В Штатах это обошлось бы в пару сотен долларов в месяц. Стоимость ведения бизнеса. Делай как надо или не делай вообще.

Тебе даже не нужен PI space — просто сгенерируй уникальный локальный префикс fc00::/7. Сейчас практика такова: используют fd00::/8 с последующими 40 битами, сгенерированными достаточно случайным образом, чтобы получить случайный уникальный /48 префикс. http://unique-local-ipv6.com/ Эти префиксы аналогичны RFC1918 частным IPv4 диапазонам 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16, за исключением того, что они настолько многочисленны, что если сгенерировать один случайным образом, шансы встретить кого-то ещё, использующего тот же самый, чрезвычайно малы (один к триллиону).

Что касается PI, но без BGP — учитывая, что IPv6 позволяет складывать заголовки, возможно, в использовании появится новый заголовок, похожий на всеми ненавистный source routing, но более безопасный и прозрачно согласовываемый. Возможно, можно придумать новый RR, который позволит любому посмотреть текущий адрес твоего роутера и добавить заголовок к пакетам, который твой роутер сможет использовать для маршрутизации пакета внутри твоего AS. Твой файрвол просто мог бы отбрасывать пакеты с такими заголовками, предназначенными не для твоей сети…

Согласен с предыдущим вариантом заголовка "source route". Я просто вслух рассуждал, что что-то чуть более структурированное, возможно, на основе хешей, может быть работоспособным таким образом, чтобы не требовать ужасно огромную таблицу маршрутизации. Если бы стандартной практикой для каждого ISP/NSP было бы предоставление "переносимых IP-точек", которые работали бы с такой схемой, и переносимые префиксы клиентов были бы доступны через службу, например, DNS, то это облегчило бы глобальную нагрузку на действительно гигантскую таблицу маршрутизации. Я не читал про переполнение стека пакетов, но меня это не удивляет… Похоже, вот почему я сам не пишу RFCs. (Я все-таки не работаю в IETF, верно?)

По поводу проблемы с PI-префиксами (ты выясняешь после 3 часов отладки, что хост выбрал глобальный адрес вместо локального, а файрвол его заблокировал) — это неважно, используешь ты PI или fd00:dead:beef::/48. Настрой файрвол правильно, и проблем не будет. (Глобальный адрес все равно динамический, даже с nptv6). Я не против того, чтобы у всех были PI-адреса (это было бы неплохо — и если есть способ эффективно маршрутизировать их все без таблиц маршрутизации объемом 2 ТБ везде — тем лучше), но поскольку большинство людей не смогут получить маршрутизацию, нет необходимости "сжигать" реальные адреса за NAT (или параллельно с динамическими реальными — смотри мой комментарий про отсутствие "культа" в конце этого, признаться, длинного поста).

Что касается NPTv6, если бы существовал только stateless-префикс-обменник NAT, я бы был немного более расположен к этому, но чувствую, что это как дать мышке печенье, и она потребует молока. Развертывания и функции NAT будут расти как снежный ком, и v6 станет таким же запутанным, как v4, когда v6 мог бы быть гораздо проще. Вы удивитесь, насколько медленно шел переход на NAT — мне приходилось уговаривать не слишком разбирающихся в сетях IT-подрядчиков клиентов, чтобы они поверили, что почтовый сервер и веб-сервер могут использовать один и тот же публичный IP при использовании NAT. (Тогда клиенты регулярно получали сети /26 и /25 на своих ISDN-соединениях, и я был королем NAT. Если они не знали, как использовать name virtual hosting — тогда это было очень новой вещью — я им говорил: «извините, но так уж получилось!». Несколько доменов – это не повод для нескольких IP-адресов!)

Хотя в ранние дни расширения IPv4 я был ранним энтузиастом (королем) NAT, теперь я решительно выступаю за отказ от него. Я вижу IPv6 как шанс начать все с чистого листа и решить наши проблемы новыми способами, которые не требуют нарушения сквозной связи.

Один из аспектов IPv6, в который я не попал в ряды "поклонников" — это вся эта идея о том, что IPv6 — это практически бесконечный ресурс. Текущие методы распределения — ну, слово «расточительность» просто не подходит, чтобы это описать. /56 для домашних пользователей??? Я, знаете ли, нуждаюсь в 256 сегментах сети у себя дома! Да-да! И даже чувствую себя расточительным, просто имея /60, который я использую в настоящее время! И еще есть сеть моей компании, в которой тысячи хостов в нескольких офисах в нескольких штатах, но нам хватает примерно 256 сегментов IPv4… Один /52 хватило бы нам надолго, но текущие рекомендации по распределению легко могли бы оправдать нам /40.

Хорошо подмечено. Объявлять 2 префикса с RA и с небольшим временем жизни. Переход на резервный режим — отключать объявление префикса. Любой тип NAT, кроме 6to4, для хостов, использующих только IPv6, следует упразднить. Точка бессмысленных распределений на самом деле не обоснована. Адресное пространство настолько огромно, что это не имеет значения.

/56 для домашних пользователей может быть излишним, но лучше, чем та весьма тревожная тенденция, которую я всё чаще вижу: им выдают всего один динамический /64 и всё. Я не представлял, что адресов для всех, которых должно было принести IPv6, будет так мало. Да, можно спрятать весь IPv4-интернет в это количество раз, но даже простейшую гостевую LAN сделать не получится, потому что всё требует минимум /64. Чуть более по теме, в последний раз, когда я пытался использовать локальные fd00::/8 адреса, всё прошло не очень хорошо. Windows 7 без проблем получила как локальные, так и публичные адреса, но потом настояла на использовании локального адреса практически для всего. Подключиться к Google из fd не получается. Можно перенастроить, и, судя по всему, это уже сделано по умолчанию начиная хотя бы с Windows 8.1, но учитывая текущую долю операционных систем, локальные адреса пока не совсем plug and play.

Да, конечно, есть трудности, которые нужно преодолеть. Это точно. Я имею в виду, когда я начинал, DHCP был чем-то редким. Мне приходилось обходить множество офисных LAN, чтобы настроить новый публичный IP-адрес на каждом компьютере (и перезагружать - Windows 3.11/Win95 не позволяли просто так это менять), каждый раз, когда мы подключали нового T1 или ISDN-клиента. Они дойдут до этого. Черт возьми, ROS даже не поддерживает stateless DHCP-сервер для выдачи информации, такой как DNS-сервера, доменное имя и т.д. (Нормис! Когда мы можем это ожидать!?!?!??) Интересно насчёт выбора исходного адреса.

Ты потерял моё внимание с фразы "ssl vpns лучше". Лол. Серьёзно? Да, по очень простой причине: SSL/TLS — это проверенный протокол с широким распространением и достаточно хорошим пониманием принципов работы в сообществе безопасности. IPSec же, наоборот, оставляет слишком много возможностей для администратора, что в итоге приводит к тому, что для его настройки между разными вендорами уходят дни, а параметров настолько много, что никто даже не удосужился провести комплексное исследование безопасности. Нет, правда, попробуйте найти научный анализ безопасности IPSec — его просто не существует. IPSec как XML: все говорят, что он используется в корпоративной среде, значит, он должен быть хорошим, но как только начинаешь искать реальный источник, ничего не находит (я с другом потратили пару дней, чтобы найти надёжный источник для общепринятого мнения, что "SOAP повсюду в корпоративной среде" для научного отчёта. Мы практически ничего не нашли). Даже клиент Cisco Anyconnect использует OpenSSL. И хотя OpenSSL переживал не самые лучшие моменты, это достаточно хорошо изученный и проверенный продукт. Над безопасностью OpenSSL проводят множество исследований (аргументированно и от черных, и от белых шляп), поэтому когда обнаруживается уязвимость, обычно не затягивается с её публичным раскрытием и исправлением. Я никогда не видел ничего подобного с IPSec. Сделайте поиск в Google по запросу "ssl secure configuration", и уже первый результат предоставит вам хороший список рекомендаций. С IPSec настолько сложно, что большинство людей даже не заморачиваются после того, как каким-то образом заставят его работать (вспомним, мы уже потратили пару дней на возились с параметрами). Также, в отличие от IPSec, который нарушает модель OSI, что в свою очередь делает его настоящей головной болью, SSL/TLS очень переносим, особенно если подумать о брандмауэрах и http-прокси. Вся моя речь о VPN удалённого доступа, Site to Site VPN — это другой вопрос. Также признаю, что хотя бы IPSec является стандартом, в то время как каждый вендор сейчас придумывает свой собственный протокол для SSL-VPN, я уверен, что в будущем мы увидим некоторую стандартизацию в этой области.