[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3

Вот еще в голову пришло. У тебя увеличивается заголовок на 32 бита. Все остальные процедуры остаются теми же. Что будем с MTU делать? В IPv6 это продумано. 2015-02-01 15:50 GMT+02:00 Anton Turygin :

Я все равно не вижу кардинальных различий в твоем подходе. Кроме того, что ТЫ думаешь, что это будет удобно. Я же вижу те же оверлеи и те же проблемы. .

...

Я не думаю, что эта проблема сложнее, чем засовывание 32-битных ASN в bgp updates. В конце концов, ничто не мешает сделать новые типы LSA для передачи информации о роутинге 64-битных префиксов. Надо, конечно, не потерять сходимость для случая, когда часть маршрутизаторов поддерживает 64-битные IP, а часть не поддерживает, но всё можно решить.

Есть одно кардинальное отличие. В BGP можно хоть батоны сигналить. И там есть AS-TRANS. Использование коей, в принципе, не рушит общей архитектуры. Если бы все можно было решить, то кто бы стал заморачиваться с OSPFv3?

...

Юзерам, нокерам и админам действительно ничего, кроме апдейта, делать не нужно.

Ага. ОПСОСам расскажи, как им ничего в такой схеме не надо будет делать :)

2015-02-01 15:30 GMT+02:00 Pavel Gulchouck :

...

On Sun, Feb 01, 2015 at 02:51:08PM +0200, Anton Turygin writes:

...

2015-02-01 14:44 GMT+02:00 Pavel Gulchouck :

...

On Sun, Feb 01, 2015 at 02:13:57PM +0200, Anton Turygin writes:

...

2015-02-01 12:33 GMT+02:00 Pavel Gulchouck :

...

On Sat, Jan 31, 2015 at 11:37:08PM +0200, Anton Turygin writes: > Кстати, в реалиях адресации сети "обратной совместимости" мало. Нужна полная.

Полная необязательна. Да и недостижима. Маршруты от/к ресурсам, живущим на новых адресах, будут естественным образом обходить операторов, эти адреса не поддерживающих. Обратная совместимость явно лучше полного отсутствия совместимости, которое мы имеем с IPv6.

А что делать сетевым элементам, которые уже имеют новую адресацию, но имеют необходимость доступа к старым элементам?

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

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

Ну да. У нас вместо 32 бит адрес теперь 64 бита, но делать ничего не надо. Какая-то утопия :-) И роутинг, и фаервол и т.д. Все надо.

Надо для кого - для юзера, для нокера, для админа, для разработчика клиентского софта, для разработчика софта маршрутизатора и операционки?

Юзерам, нокерам и админам действительно ничего, кроме апдейта, делать не нужно. Имеющаяся таблица роутинга продолжает работать, и все IP префиксы от 1.0.0.0.0 до 255.255.255.255.255.255.255.255 роутятся по дефолту, пока не появляются более специфичные маршруты для них. Фаервол тоже никак не меняется.

Разработчику софта нужно пересобрать его с новыми хидерами и либами и проверить, что всё работает корректно. Конечно, если он заложился на размер struct in_addr или выводит IP-адрес вызовом printf("%u.%u.%u.%u", ...), то ему придётся внести некоторые изменения. Но эти изменения минимальны, они несравнимы с добавлением поддержки IPv6.

А разработчику OS - да, нужно будет поменять. Но, опять же, эти изменения несравнимо проще, чем реализация IPv6.

...

Как пример, который мне сразу в голову пришел - 64 bit не засунуть в 32 bit в OSPFv2 LSA.

Я не думаю, что эта проблема сложнее, чем засовывание 32-битных ASN в bgp updates. В конце концов, ничто не мешает сделать новые типы LSA для передачи информации о роутинге 64-битных префиксов. Надо, конечно, не потерять сходимость для случая, когда часть маршрутизаторов поддерживает 64-битные IP, а часть не поддерживает, но всё можно решить.

...

Ну видишь. Проапдейтиться. Чем подход в корне отличается от подхода с IPv6? Всех в один момент проапдейтиться не заставишь. Либо нат-тунель, либо очередной дуал стек.

Не надо всем одновременно. Равно как не надо всем одновременно включать поддержку IPv6 или HTML5.

Вот, кстати, насчёт HTML5. Аналогом IPv6 тут был бы вариант, когда каждый сайт доступен в двух вариантах (HTML и HTML5), и у каждого пользователя два браузера. И такая ситуация предполагается всегда. Разве не кошмар?

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

Никакой дуал стек не нужен, на каждом шагу с каждой стороны есть вполне понятная мотивация, зачем апдейтиться и поддерживать 64-битные IP.

А поддержку IPv6 после этого можно будет выкинуть за ненадобностью. :)

...

...

...

...

> 2015-01-31 14:52 GMT+02:00 Pavel Gulchouck : > > On Wed, Jan 28, 2015 at 11:04:49PM +0100, Andrei Kozlov writes: > >> Думаю, не все так безоблачно, с модификацией заголовка, как кажется на > >> первый взгляд. Неиспользуемые широкой общественностью биты могут быть > >> задействованы в экпериментальных и прочьих проприетарных целях. Для таких > >> случаев, решение подлатать на время v4 - кошмар. > >> > >> На мой взгляд, v6 - рациональное решение, даже с некоторой изящной > >> эволюционной составляющей. В основе 2 очень важные вещи: > >> > >> - учтены недостатки v4 и проявленя забота о соседях по OSI; > >> - обширные возможности по безболезненному переходу на новый протокол. > >> > >> Бизнес-кейс для перехода, по большому счету, отсутствует (пока), что в > >> существенной степении тормозит процесс. Но это не является недостатком > >> протокола, imho. > > > > IPv6 - epic fail, который затормозит развитие цивилизации. :) > > > > - Нет обратной совместимости на уровне API и приложений; для > > поддержки IPv6 софт нужно не просто перекомпилировать (как, например, > > для 64-битного time_t или off_t), а существенно переписывать; > > - нет обратной совместимости на уровне протоколов маршрутизации; > > для роутинга IPv6 нужно поднимать отдельные BGP-сессии, строить > > отдельный OSPF и т.д., а не просто проапдейтить прошивку, как для > > поддержки AS32; > > - адреса занимают больше одного регистра современного процессора, > > поэтому с ними нужно обращаться как с массивами, а не как с int, > > что получается заметно менее удобно и эффективно, хотя 64-битных > > адресов было бы с головой достаточно - это примерно количество > > песчинок во всех пустынях Земли; это не в два раза больше, чем > > 32-битных, а в четыре миллиарда раз больше; > > - нет ни одного сколь-нибудь серьёзного изменения/улучшения, которое > > оправдывало бы отказ от обратной совместимости. > > > > Отсутствие обратной совместимости приводит к тому, что IPv6 не > > заменяет собой IPv4, а строится рядом с ним, параллельно и независимо. > > А значит, IPv6 не решает проблему дефицита IPv4-адресов - IPv4 будут > > необходимы сетевым ресурсам, пока будут оставаться IPv4-пользователи, > > т.е. всегда. А если IPv6 не решает глобальную проблему дефицита > > IPv4-адресов, но создаёт много проблем, зачем он вообще нужен? > > > >> 2015-01-28 11:58 GMT+01:00 Andrii Stesin : > >> > >> > а всего-то надо было инвентаризовать де-факто неиспользуемые байты в > >> > заголовке IPv4 и парочку из них использовать чтобы добавить перед > >> > имеющимися четырьмя одля адресации, еще на 100 лет бы хватило...

-- Паша.