ipv6

[gul_tech]

Хочу ipv7 (или какой там следующий свободен).
В смысле, не хочу ipv6.
Хочу, чтобы всё было как в IPv4, но только адреса 64-битные. Обычный u_int64_t. Одно слово (один регистр) на 64-битных архитектурах.
Лёгкий переход, минимальные правки в софте, количества хватит навсегда, эффективнная обработка... Примерно как с asn16 перешли на asn32 без лишнего шума и потрясений.
Не ощущаю я счастья от ipv6. И ощущаю гемор ещё долгие годы, от параллельного существования ipv4 и ipv6, от невозможности интернетовским ресурсам полноценно существовать только на ipv6 без ipv4 при невозможности безболезненно получить блок ipv4, от неготовности всяких железок к ipv6 (фаерволы, wifi ap, телефоны и т.д.)...

Comments

[dbg.livejournal.com]

Схема "все то же самое, только длиннее" страдает ровно от того же, что и ipv6 - от остутствия обратной совместимости. Поэтому "гемор на долгие годы" будет и в таком раскладе, ровно с теми же эффектами.

А сравнение asn16/32 - некорректно. Там совместимость как раз была обеспечена.

[gul-kiev.livejournal.com]

Ну да, нужна обратная совместимость.
Строить отдельные линки ipv4 и ipv6, иметь отдельные таблицы роутинга, отдельные route-maps - это не дело. Пока нормально работает ipv4, никто не будет сильно париться построением ipv6, скорее будут спекулировать адресами, по монотонно растущим ценам.

А если таблица роутинга та же, в bgp capability (ip64 compatible), тогда все будут заинтересованы в том, чтобы поддерживать ip64. Потому что "у вас нету, а у них есть, я к ним пойду". Пользователь просто с очередным апдейтом софта вместо 32-битной таблицы роутинга получил бы 64-битную. Девелопер сделал бы минимальные контекстные правки и перекомпилил (а если всё совсем хорошо написано - просто перекомпилил).

Не вижу принципиальных причин, мешающих сделать 64-битные IP с сохранением обратной совместимости. Формат пакетов, разумеется, другой - на каждом сетевом линке известно, поддерживает ли удалённая сторона ip64. Соответственно, маршруты для ip32 и ip64 могут быть разными - ip64 обходят узлы, на которых нет поддержки ip64 (bgp, ospf). Но, опять же, это не мешает обратной совместимости и не требует построения второй, независимой системы параллельно уже существующей, достаточно просто проапдейтить софт, а это рано или поздно сделают все.

[dbg.livejournal.com]

"Формат пакетов, разумеется, другой" - ну вот и привет, никакой совместимости. Один хост с другим не поговорит без специальных отжиманий. Тот же IPv6, вид с боку.

[gul-kiev.livejournal.com]

Ну почему же.
Вот у ESMTP команды не те, что у SMTP, что не мешает обратной совместимости.
Если у пакета оба адреса 32-битные, шлём его в старом формате, если хотя бы один из адресов большой (64-битный) - в новом.
В конфигурации интерфейса можно флагом выставлять, какие пакеты туда отправлять. Можно и все пакеты слать в новом формате, типа tagged native vlan.
Новый софт принимает пакеты и в новом, и в старом формате. Старый софт - понятно, только в старом.

Принципиально, что ни пользователям, ни админам не нужно ничего специально конфигурировать (получать блоки адресов, строить bgp и т.д.) - просто проапдейтили софт и всё завелось. Это реальная схема расширения адресного пространства. А строить с нуля новую параллельно - нереальная. Потому что пока она работает хуже, чем старая, она будет вторична. А пока она вторична, она будет работать хуже, чем старая. И всегда найдутся ленивые админы, фирмы на старом оборудовании, автопилотные узлы и идейные противники ipv6, которые не будут поддерживать ipv6, и не будут от этого испытывать никаких неудобств.

ipv6

[(Anonymous)]

Все те же грабли что и при ipv6. Точно также нужно менять железо в ASICs которого гвоздем вбита структура TCAM. Точно также нужно придумывать способ доставки пакетов между IPng-speakers и IPv4-only по дороге. Точно также нужно везде где можно обновлять софт. И что в итоге? Только уменьшение размера поля адреса с 128 до 64 бит? И зачем?

Я согласен, что ipv6 кривой, но так и ipv4 кривой. Только по-своему.

- случайно заглянувший dmitry@ ;-)

Re: ipv6

[gul-kiev.livejournal.com]

> Точно также нужно придумывать способ доставки пакетов между IPng-speakers и IPv4-only по дороге.

Ну теоретически, если за пару лет вендоры озаботились бы поддержкой этого IPng, то связность получилась бы. А дальше - пакеты IPng находят себе дорогу через IPng-speakers, в обход старых систем, без туннелирования. Собственно, сейчас даже мировая IPv6-связность есть без туннелей, хотя для этого нужно было не только железо и софт проапдейтить, но и адреса получить и линки построить. А после появления связности старые системы будут озабочены тем, чтобы поддерживать IPng, чтобы не терять деньги.

> И что в итоге? Только уменьшение размера поля адреса с 128 до 64 бит? И зачем?

В итоге:
1. Простой и естественный для пользователей и админов переход на новые адреса.
2. Замена старого на новое, поглощение старого новым, а не построение нового рядом со старым.

Чтобы новое нормально жило, старое должно быть разрушено или поглощено. С IPv4 этого не предвидится. А потом и переходить на IPv6 не будут, и проблемы с дефицитом IPv4-адресов будут ещё долго.

Вот есть xmpp, но юзеры по-прежнему плакали, кололись стиснув зубы юзают icq, даже несмотря на наличие гейтов и отсутствие необходимости ставить другой софт. То же будет и с IPv4. Будет старый софт, который поддерживает только IPv4 (или глючит на IPv6), будут трассы IPv4 короче, чем IPv6, будут админы, говорящие "выкинь ipv6, это кака"... И никуда проблемы IPv4 не денутся.

IPv6 - это новая сущность, не приспособленная для того, чтобы решить проблемы IPv4.

Re: ipv6

[zwstl.livejournal.com]

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

Вы не поверите, но большинство использует клиент от icq, а не более функциональные альтернативы.
А Вы говорите о xmpp, для которого нет готового клиента со встроенной интеграцией с icq. Чтобы поставил - и заработало всё, включая поиск.

Но сравнивать ситуацию с IM протоколами и IP некорректно. Об этих протоколах знают только специалисты(максимум что знает типовой пользователь - ip адрес в свойствах сетевой карты. О котором он узнает, как правило, при вопросе по телефону - "а какой у вас ip адрес").

Теперь по теме:
Если бы разработчики IPv9 пытались сделать совместимость с IPv4, то:
1. вероятнее всего стандарта не было бы до сих пор
2. перетащили многие проблемы IPv4 на IPv9

Re: ipv6

[gul-kiev.livejournal.com]

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

Я в другой ветке говорил: конечно, после драки кулаками не машут. Но поскольку убирать поддержку IPv4 никто не собирается, проблемы с исчерпанием пространства IPv4 тоже никуда не денутся, IPv6 их не решит. А потому вполне допускаю, что замена IPv4 на такой IPv9 всё равно будет сделана, лет через 5. IPv6 только помешал этому, отодвинув решение проблемы.
А потом и про IPv6 можно будет забыть, потому что он за эти годы так и не станет единственным или даже первым из протоколов.

[gul-kiev.livejournal.com]

Кроме того, в той ситуации с ipv6, которая сейчас есть, ipv4 никуда не денется, и будет продолжать работать, но будет приобретать нездоровую элитарность. Даже не как короткие домены под com, а ещё хуже.
А если бы была схема "включил поддержку нового протокола и она поглотила старый", тогда 32-битные ip-адреса были бы интересны не больше, чем шестизначные номера icq или трёхзначные номера AS.

[dbg.livejournal.com]

Ну, "илитарность" - это вариант для совсем ебанутых. По мне, так и хер с ними, пусть остаются за бортом эволюции.

> А если бы

Нету у нас варианта "а если бы". Проехали. Надо было 10 лет назад трепыхаться. Теперь только вперед и с песней. Будет больно, да. Но надо.

[gul-kiev.livejournal.com]

> Ну, "илитарность" - это вариант для совсем ебанутых. По мне, так и хер с ними, пусть остаются за бортом эволюции.

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

> Нету у нас варианта "а если бы". Проехали. Надо было 10 лет назад трепыхаться.

А думаю, что будет.
То есть, будет больно, вперёд, с песней на IPv6 - ну и что? Ну пусть даже заработает оно. Но проблемы IPv4 от этого ведь никуда не денутся. Равно как появление tld .me, .info и прочих не решило вопрос дефицита доменов *.com. Выключать IPv4 ведь никто не собирается, а потому и проблемы никуда не денутся. И их нужно будет решать - не сейчас, так через 5-10 лет, когда IPv6 уже будет вовсю работать.

[asrhayader.livejournal.com]

Да, хорошо было бы если б внедрили обратно совместимую схему... Но не сложилось
А IPv6 придется внедрять у ISP, RIPE уже сеток больше не даст, а клиентов новых надо сажать... Хотя думаем и про вариант с NAT

[zwstl.livejournal.com]

Есть ipv8 и ipv9

[netch80.livejournal.com]

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

[gul-kiev.livejournal.com]

> за счёт расширения адресного пространства

Дело в том, проблема адресного пространства не решается. Дефицит адресов IPv4 как был, так и будет и через 5, и через 10 лет. IPv6 - другая сущность с несколько другой сферой применения. Для всяких мобильных GPRS подходит, а для более классических применений оно менее удобно, чем IPv4.

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

Даже если не делать обратную совместимость на уровне протокола - почему бы не попытаться сделать обратную совместимость или хотя бы смягчить переход на уровне API и на уровне конфигурации оборудования? Это ведь совсем не трудно: если у меня и у моего соседа, с которым построена BGP-сессия, появилась поддержка IPv6, роутеры автоматически поднимают IPv6-bgp с теми же параметрами, с которыми поднято IPv4. Во многих вопросах роутеры имеют поведение по умолчанию, минимизирующее работу по их конфигурированию. А тут нет - отдельно "protocol ospf", и отдельной секцией "protocol ospf3", в котором заново все те же areas, интерфейсы, метрики и т.п. - нафига?
И особенно непонятно, почему IPv6 не включает в себя IPv4. То есть, почему, если я поднял IPv6 bgp, я не могу задаунить IPv4.

По-моему, это пример ужасно дурацкого решения, которое заметно повлияет на дальнейшее развитие IT. Вполне могло быть иначе, если бы тогда (~25 лет назад) к обсуждению этого вопроса подключился бы кто-то толковый, кому было не всё равно, что будет через 25-30 лет.