25.01.2015 22:46, Vasiliy P. Melnik пишет:

А что мешает им позвонить и спросить ?

З.Ы. укртелеком тоже начал выдавать серый айпишник адсл-абонентам, так что все изыскивают резервы. IPV4 все - новых сетей не будет. У укртелекома решается вопрос заявкой, и они начинают выдавать белый динамику. И я их очень даже понимаю.

Правильно, белые IP продать налево, а юзерам серые раздавать. Белые сейчас столько стоят, что стрёмно юзерам на шару раздавать :). Тем более, что они им на самом деле и не нужны вовсе.

25 января 2015 г., 21:54 пользователь Yuriy B. Borysov mailto:yokodzun@yokodzun.kiev.ua> написал:

Добрый вечер.

А есть ли среди подписчиков листа абоненты Freenet/O3 (Киев)? В какой-то момент заметил, что домашнему маршрутизатору выдаётся серый IP. Мне казалось, что раньше был динамический, но белый.

Действительно что-то поменялось в условиях подключений, или серые всегда были?

Спасибо!

-- WBR, Yuriy B. Borysov YOKO-UANIC | YOKO-RIPE

-- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net,

Hi, 25.01.2015 23:31, Yuriy B. Borysov пишет:

Hi!

On Sun, Jan 25, 2015 at 11:26:51PM +0200, Alexandr Baryshnyev writes:

...

Правильно, белые IP продать налево, а юзерам серые раздавать. Белые сейчас столько стоят, что стрёмно юзерам на шару раздавать :). Тем более, что они им на самом деле и не нужны вовсе.

Спорное утверждение, про нужность.

Или это сарказм?

Это суровая правда жизни. А может и сарказм, как для кого. Пока адресов было навалом, то раздавали юзерам задаром, оно ж ничего не стоило. Сейчас оно стоит очень конкретных денег и желающие купить названивают с интересными предложениями прямо на контакты из whois, так что продать налево вполне реально. А нужно оно реально незначительной части юзеров, так для тех кому реально надо, это наверное должна быть платная услуга, не? Остальные 99.9% даже понятия об IP адресах не имеют. А вот зачем домашнему юзеру белый IP? Чтобы сервер у себя дома поставить? Так это на домашних тарифах запрещено практически у всех провайдеров. -- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net

Hi! On Tue, Jan 27, 2015 at 06:45:23AM +0200, Valentin Nechayev writes:

SSH/RDP/etc. к себе домой это не сервер, но очень важная причина иметь таки белый и редко меняющийся адрес. Ну или пусть дают альтернативу в виде какого-нибудь socks.

Да фик с ним, редко меняющимся. dyndns есть, если уж что. Другое дело, что теперь только сторонние сервисы - вроде тим-вью. Ну и самое печально, отломали vpn. А вот это больно. -- WBR, Yuriy B. Borysov YOKO-UANIC | YOKO-RIPE

27.01.2015 6:45, Valentin Nechayev пишет:

Sun, Jan 25, 2015 at 23:50:33, abb wrote about "Re: [uanog] Белые IP Freenet/O3":

...

А вот зачем домашнему юзеру белый IP? Чтобы сервер у себя дома поставить? Так это на домашних тарифах запрещено практически у всех провайдеров.

SSH/RDP/etc. к себе домой это не сервер, но очень важная причина иметь таки белый и редко меняющийся адрес. Ну или пусть дают альтернативу в виде какого-нибудь socks.

Вообще-то правильно было бы давать юзеру возможность в личном кабинете настраивать портмапинг для доступа извне ну и да, dyndns. Там же можно было бы сделать регулировку тайм-аута и смену внешнего IP по запросу юзера. Но это ж надо чтобы юзер понимал, что делает, а то он там такого накрутит... А учитывая, что это мало кому надо на самом деле, то нет смысла и реализовывать тонкую настройку НАТ в личном кабинете, себе - же проблем меньше. Непонятно желание требовать слепого соблюдения контракта. Обстоятельства изменились сильно - вот и вынуждены многие провайдеры переходить на раздачу серых адресов, это можно понять, ИМНО. В договоре всё не предусмотришь, а размахивать адвокатами и судами - не наш метод, у нас тут не штаты пока ещё. Ну и голосование ногами никто не отменял - насильно мил не будешь, выбор провайдеров пока еще велик, есть из чего выбрать. Ну и, если уж на то пошло, у всех провайдеров есть дополнительная услуга за небольшие дополнительные деньги - белый статический IP. Кому надо, то, я думаю, уж как нибудь можно выкроить дополнительные 10-20грн к абонплате за такое удобство. Мы вот раздаём белые адреса, но это до тех пор, пока они есть. Как закончатся - альтернативы НАТ-у нет в обозримом будущем. Сначала придётся переходить на серые адреса на дешёвых тарифах, а там - кто знает? Новые IP взять негде, это не реально. Ipv6, о которых так много говорили большевики, так и не взлетело, так шта...

-netch-

-- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net

27.01.2015 11:35, Yuriy B. Borysov пишет:

Hi!

On Tue, Jan 27, 2015 at 11:25:45AM +0200, Alexandr Baryshnyev writes:

...

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

Но есть же элементарная вежливость - меняете параметры, которые могут повлиять на сервис клиента, сообщите хотя бы в личном кабинете или письмом. Я вот например был вынужден прыгать с gprs в связи со сломавшимся внезапно pptp.

Это да, предупреждать надо, в особо важных случаях и в новостях на сайте и в личном кабинете и по электропочте и SMS-рассылкой. Но, из практики: как ни предупреждай, а половина юзеров всё равно потом будет говорить, что они ничего не знали и не видели. А вторая половина будет бомбить техподдержку вопросами типа: а что это такое и зачем оно надо и чем мне грозит? А низачем не надо и ничем не грозит для подавляющего большинства. Если, конечно, правильно настроено. -- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net

Today Jan 27, 2015 at 11:25 Alexandr Baryshnyev wrote:

...

SSH/RDP/etc. к себе домой это не сервер, но очень важная причина иметь таки белый и редко меняющийся адрес. Ну или пусть дают альтернативу в виде какого-нибудь socks.

Вообще-то правильно было бы давать юзеру возможность в личном кабинете настраивать портмапинг для доступа извне ну и да, dyndns. Там же можно было бы сделать регулировку тайм-аута и смену внешнего IP по запросу юзера. Но это ж надо чтобы юзер понимал, что делает, а то он там такого накрутит...

Портмаппинг - это в случае NAT, а он IP мало экономит :) Тут же операторы делают PAT и могут ещё в разные IP транслировать параллельные сессии от одного абонента к разным хостам. -- WNGS-RIPE

On Wed, Jan 28, 2015 at 09:45:21AM +0100, Mike Petrusha wrote:

Hi Alexandr,

...

Мы вот раздаём белые адреса, но это до тех пор, пока они есть. Как закончатся - альтернативы НАТ-у нет в обозримом будущем. Сначала придётся переходить на серые адреса на дешёвых тарифах, а там - кто знает? Новые IP взять негде, это не реально. Ipv6, о которых так много говорили большевики, так и не взлетело, так шта...

Если уж NAT, то не лучше ли сразу NAT64? Как-то оптимистичнее выглядит.

Писецмистичнее - это равносильно написанию объявы "завтра мы на 6 переходим, дорогие клиенты без поддержки 6 - идите к Пу!". Ясно, что можно "почуть-чуть", но, думаю, это нереальная задача для уже подключенных абонентов. А бегущим в суд - можно всегда дать 1 "белый" в6 адрес! :). Если, конечно, в договоре про в4 не додумались ничего написать на свою голову. -- Best regards, Paul Arakelyan.

Сто процентов. Его только набрать чтобы пропинговать уже чего стоит :-) ----- Original Message ----- From: "Andrii Stesin" To: "Paul Arakelyan" Cc: "Mike Petrusha" ; "Alexandr Baryshnyev" ; "List, Uanog" Sent: Wednesday, January 28, 2015 12:13 PM Subject: [uanog] Re: [uanog] Белые IP Freenet/O3

IPv6 это типичный mega fail потому, что был разработан "комитетом"...

Думаю, не все так безоблачно, с модификацией заголовка, как кажется на первый взгляд. Неиспользуемые широкой общественностью биты могут быть задействованы в экпериментальных и прочьих проприетарных целях. Для таких случаев, решение подлатать на время v4 - кошмар. На мой взгляд, v6 - рациональное решение, даже с некоторой изящной эволюционной составляющей. В основе 2 очень важные вещи: - учтены недостатки v4 и проявленя забота о соседях по OSI; - обширные возможности по безболезненному переходу на новый протокол. Бизнес-кейс для перехода, по большому счету, отсутствует (пока), что в существенной степении тормозит процесс. Но это не является недостатком протокола, imho. 2015-01-28 11:58 GMT+01:00 Andrii Stesin :

а всего-то надо было инвентаризовать де-факто неиспользуемые байты в заголовке IPv4 и парочку из них использовать чтобы добавить перед имеющимися четырьмя одля адресации, еще на 100 лет бы хватило...

2015-01-28 23:06 GMT+01:00 Andrii Stesin :

2015-01-29 0:04 GMT+02:00 Andrei Kozlov :

...

Бизнес-кейс для перехода, по большому счету, отсутствует (пока), что в существенной степении тормозит процесс. Но это не является недостатком протокола, imho.

Так а что тогда является, если не?

Вопрос располагает к диалектическому дискурсу в духе "что русскому хорошо, то немцу - смерть".

Какие предложения? Как это можно было сделать "обратно совместимым"? Кстати, в реалиях адресации сети "обратной совместимости" мало. Нужна полная. 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 лет бы хватило...

-- Паша.

плюс к Паше по всем пунктам, и еще один важный пункт - к проектированию нового стека не подпускать комитеты 2015-02-01 12:33 GMT+02:00 Pavel Gulchouck :

On Sat, Jan 31, 2015 at 11:37:08PM +0200, Anton Turygin writes:

...

Какие предложения? Как это можно было сделать "обратно совместимым"?

Чтобы полностью ответить на этот вопрос, нужно потратить много времени и оформить ответ в виде RFC. :)

В общих чертах. ...

Андрей, А чем тебя пугают комитеты? В них участвуют представители вендоров, операторов и т.д. Я думаю, что там коллективный разум шибко помощней, чем наши потуги в uanog. 2015-02-01 12:41 GMT+02:00 Andrii Stesin :

плюс к Паше по всем пунктам, и еще один важный пункт - к проектированию нового стека не подпускать комитеты

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

...

On Sat, Jan 31, 2015 at 11:37:08PM +0200, Anton Turygin writes:

...

Какие предложения? Как это можно было сделать "обратно совместимым"?

Чтобы полностью ответить на этот вопрос, нужно потратить много времени и оформить ответ в виде RFC. :)

В общих чертах. ...

Так а чем конкретно тебя пугает IPv6? Выглядит страшно? 2015-02-01 14:40 GMT+02:00 Andrii Stesin :

Ага, вот в итоге IPv6 и получился. Результатами пугают.

2015-02-01 14:30 GMT+02:00 Anton Turygin :

...

Андрей,

А чем тебя пугают комитеты? В них участвуют представители вендоров, операторов и т.д. Я думаю, что там коллективный разум шибко помощней, чем наши потуги в uanog.

Почему неочевидно? Я применял и применяю. И в дуал стеке, и в тунелях. Все достаточно замечательно и гибко. 2015-02-01 14:54 GMT+02:00 Andrii Stesin :

Да странная такая получилась штука, типа метрового фаллоса - визуально впечатляет, но практическое применение неочевидно.

2015-02-01 14:44 GMT+02:00 Anton Turygin :

...

Так а чем конкретно тебя пугает IPv6? Выглядит страшно?

2015-02-01 14:40 GMT+02:00 Andrii Stesin :

...

Ага, вот в итоге IPv6 и получился. Результатами пугают.

Так подожди. Все тобой высказанное не является проблемой IPv6, как технологии. 2015-02-01 15:20 GMT+02:00 Andrii Stesin :

Ну вот это ты такой молодец, инноватор. А что говорит статистика? Рискну предположить, что чуть менее чем 100% ISP не заморачиваются и дают пользователям IPv4 - низкодоходным NAT, высокодоходным "кому что надо". Потому что на стороне *пользователя* нифига не инноваторы настраивают оборудование ;)

Можно конечно давать и v6 в нагрузку - в итоге геморроя больше, а доходов столько же. Никто и цента не доплатит за это. Так а смысл? Чисто инженерам на поиграться хиба шо.

Хостинг провайдеры наверное больше заинтересованы в v6 propagation но тоже воприс, в обозримой перспективе я не представляю себе коммерчески интересного сайта который был бы IPv6 only (разве шо пиратский ;)

2015-02-01 15:00 GMT+02:00 Anton Turygin :

...

Почему неочевидно? Я применял и применяю. И в дуал стеке, и в тунелях. Все достаточно замечательно и гибко.

Hi Andrii, Вся история как раз оттого, что нек-рые считают, что интернет через NAT не работает. Оттого и v4 адреса разобрали, и IPv6 придумали. Удивительно.

Ну вот это ты такой молодец, инноватор. А что говорит статистика? Рискну предположить, что чуть менее чем 100% ISP не заморачиваются и дают пользователям IPv4 - низкодоходным NAT, высокодоходным "кому что надо". Потому что на стороне *пользователя* нифига не инноваторы настраивают оборудование ;)

-- Mike Когда долго бегаешь за собакой, становишься пограничником.

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

On Sat, Jan 31, 2015 at 11:37:08PM +0200, Anton Turygin writes:

...

Кстати, в реалиях адресации сети "обратной совместимости" мало. Нужна полная.

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

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

Если у пакета src и dst являются 4-байтными, он отправляется как обычный IPv4, если хотя бы один из адресов большой - отправляется в новом формате.

Ну вот не понимает мой стек нового формата. А он ко мне прилетает.

...

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 лет бы хватило...

-- Паша.

2015-02-01 14:18 GMT+02:00 Valentin Nechayev :

hi,

Sun, Feb 01, 2015 at 14:13:57, anton wrote about "[uanog] Re: [uanog] Белые IP Freenet/O3":

...

Ну вот не понимает мой стек нового формата. А он ко мне прилетает.

И проигнорирует, естественно. В этом нет проблем. На переходный период потребуются и прокси, и спец. NAT, и многое другое, но сам переход будет значительно мягче и проще.

Все перечисленные тобой вопросы как раз решаются очевидно и тривиально. Там есть другие серьёзные вопросы, но тут они не поднимались.

В том то и дело, что они не решаются в предложенном варианте. Нет совместимости. Никакой. Как этот вариант решает проблемы IPv6 - не пойму. Все равно нужен нат, тунели и т.д. И, кстати, там что-то было про дополнительный capability к протоколам маршрутизации. Интересно, а дополнительный capability позволит засунуть 64 bit в 32 bit в OSPF LSA, например?

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 бита, но делать ничего не надо. Какая-то утопия :-) И роутинг, и фаервол и т.д. Все надо. Как пример, который мне сразу в голову пришел - 64 bit не засунуть в 32 bit в OSPFv2 LSA.

...

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

То же, что сейчас делать пользователям Windows98, желающим подключиться, например, к gmail. Проапдейтиться.

...

...

Если у пакета src и dst являются 4-байтными, он отправляется как обычный IPv4, если хотя бы один из адресов большой - отправляется в новом формате.

Ну вот не понимает мой стек нового формата. А он ко мне прилетает.

Если твой стек не понимает новый формат, пакеты с новым форматом не должны на тебя маршрутизироваться. А если твой стек не понимает новый формат, а ты сам (или твои пользователи) хочешь получить доступ к новым ресурсам - см. ответ на предыдущий вопрос.

Может быть, на начальном этапе будут полезны прокси или туннели для доступа "современных" пользователей через "старых" провайдеров, как это есть для IPv6. Но это уже нюансы механизма внедрения.

Ну видишь. Проапдейтиться. Чем подход в корне отличается от подхода с 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 лет бы хватило...

-- Паша.

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

Я не думаю, что эта проблема сложнее, чем засовывание 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 лет бы хватило...

-- Паша.

On Sun, Feb 01, 2015 at 04:14:23PM +0200, Anton Turygin writes:

Вот еще в голову пришло. У тебя увеличивается заголовок на 32 бита. Все остальные процедуры остаются теми же. Что будем с MTU делать? В IPv6 это продумано.

А зачем с ним что-то делать? Если пакеты с короткими src-dst шлются в старом формате (даже если оба роутера поддерживают новый), то они не будут конвертироваться туда-сюда по пути, и, соответственно, никаких проблем с MTU возникать не будет. Если у интерфейсов одинаковый MTU, то пакет, который пришёл с одного интерфейса, сможет уйти через другой. Если MTU разные - ну, обычные для IPv4 механизмы (tcp mss, icmp needfrag и пр). Совершенно независимо от того, какой там размер ip header. -- Паша.

On Sun, Feb 01, 2015 at 05:36:16PM +0200, Anton Turygin writes:

Как ты будешь мерять MTU в транспортной сети между двумя хостами? Кто будет фрагментировать? Что произойдет, если icmp не ходит?

Ничего не изменится по отношению к тому, как оно есть сейчас.

Ты как-то очень просто смотришь на проблему. Куча сетей до сих пор строятся с 1500 на втором уровне. Твой "улучшенный" пакет даже до шлюза не долетит.

1500 - это IP (header + payload). На втором уровне больше. "Расширенный" пакет с другим заголовком и тем же 1500 IP MTU никаких дополнительных проблем не создаст. И никаких существующих не решит.

Люди головы ломают, как проблем с MTU избежать, а ты пишешь "а зачем с ним что-то делать".

Люди голову ломают и над тем, как запустить контролируемую термоядерную реакцию, например. Но зачем об этом думать тем, где это не имеет отношения к обсуждаемой задаче?

2015-02-01 16:46 GMT+02:00 Pavel Gulchouck :

...

On Sun, Feb 01, 2015 at 04:14:23PM +0200, Anton Turygin writes:

...

Вот еще в голову пришло. У тебя увеличивается заголовок на 32 бита. Все остальные процедуры остаются теми же. Что будем с MTU делать? В IPv6 это продумано.

А зачем с ним что-то делать? Если пакеты с короткими src-dst шлются в старом формате (даже если оба роутера поддерживают новый), то они не будут конвертироваться туда-сюда по пути, и, соответственно, никаких проблем с MTU возникать не будет. Если у интерфейсов одинаковый MTU, то пакет, который пришёл с одного интерфейса, сможет уйти через другой. Если MTU разные - ну, обычные для IPv4 механизмы (tcp mss, icmp needfrag и пр). Совершенно независимо от того, какой там размер ip header.

-- Паша.

On Sun, Feb 01, 2015 at 09:08:00PM +0200, Anton Turygin writes:

2015-02-01 20:56 GMT+02:00 Pavel Gulchouck :

...

On Sun, Feb 01, 2015 at 05:36:16PM +0200, Anton Turygin writes:

...

Как ты будешь мерять MTU в транспортной сети между двумя хостами? Кто будет фрагментировать? Что произойдет, если icmp не ходит?

Ничего не изменится по отношению к тому, как оно есть сейчас.

А как оно есть сейчас? Из-за этой проблемы (отчасти) фрагментацию в IPv6 переложили на плечи хостов.

...

...

Ты как-то очень просто смотришь на проблему. Куча сетей до сих пор строятся с 1500 на втором уровне. Твой "улучшенный" пакет даже до шлюза не долетит.

1500 - это IP (header + payload). На втором уровне больше. "Расширенный" пакет с другим заголовком и тем же 1500 IP MTU никаких дополнительных проблем не создаст. И никаких существующих не решит.

Ну как не создаст? MPLS метка создает проблемы (те же 32 бита), а твои 32 бита не создадут? В чем отличие?

MPLS увеличивает размер L2-пакета, потому что это более низкий уровень, чем IP. 64-битные IP увеличели бы размер L3-заголовка, соответственно, при том же MTU уменьшили размер L3 payload без какого-либо влияния на прохождение этих пакетов через оборудование.

...

...

Люди головы ломают, как проблем с MTU избежать, а ты пишешь "а зачем с ним что-то делать".

Люди голову ломают и над тем, как запустить контролируемую термоядерную реакцию, например. Но зачем об этом думать тем, где это не имеет отношения к обсуждаемой задаче?

Ну вот в этом и проблема. Что для тебя - это всего лишь каких-то 32 бита. А все остальное "как-то решится". Вот только как? Если задача - адресов расширить - тогда, конечно. Можно не думать про всякие глупости типа MTU и т.д.

Ну да, у людей тут суперструны с гравитацией не совмещаются, а мы в это время IPv6 внедряем. ;-] Ты, похоже, постоянно думаешь, что при увеличении заголовка IP на 32 бита каким-то образом размер L2-пакета должен на эти же 32 бита тоже вырасти. Но это ведь совершенно необязательно.

Относительно к IPv6, с которого все началось. Вы реально думаете, что они настолько упоротые, что не увидели "простого и элегантного" решения, в котором "все решается само"?

Я думаю, что они жили в другом веке, и плохо себе представляли степень распространения IP и сложности перехода с одного протокола на другой в то время, когда этот переход окажется необходим. Кроме того, они в уме считали прибыли от продажи железа с поддержкой IPv6, софта с поддержкой IPv6, курсов по обучению IPv6 и всего остального. Как, например, производители автомобилей - они не тупые, что ставят пластиковые бамперы, которые гнутся одновременно со всем кузовом, просто им это выгодно. В отличие от пользователей.

...

...

2015-02-01 16:46 GMT+02:00 Pavel Gulchouck :

...

On Sun, Feb 01, 2015 at 04:14:23PM +0200, Anton Turygin writes:

...

Вот еще в голову пришло. У тебя увеличивается заголовок на 32 бита. Все остальные процедуры остаются теми же. Что будем с MTU делать? В IPv6 это продумано.

А зачем с ним что-то делать? Если пакеты с короткими src-dst шлются в старом формате (даже если оба роутера поддерживают новый), то они не будут конвертироваться туда-сюда по пути, и, соответственно, никаких проблем с MTU возникать не будет. Если у интерфейсов одинаковый MTU, то пакет, который пришёл с одного интерфейса, сможет уйти через другой. Если MTU разные - ну, обычные для IPv4 механизмы (tcp mss, icmp needfrag и пр). Совершенно независимо от того, какой там размер ip header.

-- Паша.

-- Паша.

On Sun, Feb 01, 2015 at 09:46:00PM +0200, Anton Turygin writes:

...

...

Ну как не создаст? MPLS метка создает проблемы (те же 32 бита), а твои 32 бита не создадут? В чем отличие?

MPLS увеличивает размер L2-пакета, потому что это более низкий уровень, чем IP. 64-битные IP увеличели бы размер L3-заголовка, соответственно, при том же MTU уменьшили размер L3 payload без какого-либо влияния на прохождение этих пакетов через оборудование.

Что значит уменьшили payload? Вот так взяли и уменьшили?

Ну да. Когда ты говоришь, например, "mtr --psize 1500 8.8.8.8", для вычисления размера payload mtr вычитает из этих 1500 размер IP-заголовка. При установлении IP-соединения MSS тоже устанавливается не от фонаря, а исходя из MTU интерфейса и размера ip header. В чём проблема с увеличением размера ip header? В том же IPv6 тоже по умолчанию mtu 1500, ip header больше, payload меньше - где проблема? Кто знает размер payload при установлении tcp-сессии? Пользователь не знает. Программист тоже не знает. Даже маршрутизатор - и тот толком не знает, не говоря уже о свичах. Так что да, вот так взяли и уменьшили.

Так это новый стек. В чем отличие от IPv6 кроме того, что ьебе удобно читать?

Это не новый стек. Существующий стек определяет размер payload исходя из ip mtu и размера ip-заголовка. Потом может корректировать по MSS и icmp needfrag. В этом ничего менять не надо. [...]

...

Ты, похоже, постоянно думаешь, что при увеличении заголовка IP на 32 бита каким-то образом размер L2-пакета должен на эти же 32 бита тоже вырасти. Но это ведь совершенно необязательно.

Для того, чтобы оно не выросло, эти 4 байта надо где-то заимствовать.

Кто-то из нас тупит. :) Максимальный размер IP-пакета не меняется, он остаётся 1500 байт. Соответственно, размер L2-пакета тоже не меняется. Если размер ip header увеличивается, то уменьшается размер payload. Если ip header уменьшается - размер payload увеличивается. MTU всё равно остаётся 1500. Где проблема? В том, что под freebsd вместо "ping -s 1472 -D 193.0.0.100" нужно будет говорить "ping -s 1468 -D 193.0.0.100", потому что тамошний пинг, в отличие от линуксового, не вычитает sizeof(struct ip_header), или где-то ещё? Да и добавление четырёх байт к L2 header (802.1q, q-in-q) никаких особенных проблем не вызывает, но это совсем другая история.

...

...

Относительно к IPv6, с которого все началось. Вы реально думаете, что они настолько упоротые, что не увидели "простого и элегантного" решения, в котором "все решается само"?

Я думаю, что они жили в другом веке, и плохо себе представляли степень распространения IP и сложности перехода с одного протокола на другой в то время, когда этот переход окажется необходим.

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

Да, вот только подход IPv6 в части фрагментации, например, снижает требования к маршрутизаторам, убирая оттуда эту функцию. А, следовательно, снижает их стоимость.

Есть у меня большие подозрения, что при распространении IPv6 и появлении там серьёзного туннелирования с криптованием, от фрагментирования никуда уйти не получится. В IPv4 тоже TCP фрагментировать не положено, но по факту фрагментируется аж бегом.

Можно по пунктам проблемы IPv6 и чем твои 64bit лучше?

В этом треде приводил чуть раньше перечислал по пунктам.

Мы уже разобрались, что все равно нужен новый стек. Совместимости нет.

Нет, извини. Новый стек не нужен, нужна модификация старого. Полной совместимости нет, обратная совместимость есть.

Нужны новые протоколы (либо реинжиниринг старых).

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

А в IPv6, например, нет бродкаста. Переработана фрагментация. Нативный ipsec.

Ты так говоришь, как будто это что-то хорошее. :) -- Паша.

Sun, Feb 01, 2015 at 22:49:58, anton wrote about "[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3":

Ну то есть, ты предлагаешь кусок адреса засунуть в ip options? Очень плохая идея.

Аргументируй, пожалуйста. Место в номерах опций есть. Насколько я понял RFC791, опции обязательны к пониманию всеми участниками, то есть пакет не пройдёт дальше раутера, который такое не знает; то есть, неправильной интерпретации адреса не будет. Что ещё не так? Вопрос цены обработки в раутерах я тут не рассматриваю, он очевиден и не в пользу варианта Павла, но о нём речь не шла.

...

Нет, извини. Новый стек не нужен, нужна модификация старого. Полной совместимости нет, обратная совместимость есть. Я так и не понял, что такое "обратная совместимость". Ты же сам написал, что старые стеки с новыми работать не будут. Значит совместимости нет.

Есть совместимость в пределах старых возможностей и адекватная реакция на использование новых. Это и называется корректной обратной совместимостью.

...

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

Ну каких, например, нетривиальных действий? В твоем подходе тоже надо полностью перерабатывать маршрутизаторы. Переписывать логику работы ткам-ов и т.п.

Это и так делается каждые несколько лет и, как я говорил рядом, было уже однажды сделано - при переходе к безклассовому раутингу; а после этого ещё несколько раз, с каждой новой архитектурой (помнишь, например, переход IOS 11 -> 12 со введением CEF? сколько граблей было, пока оно не начало полностью корректно работать?) Или, переход концепции Cisco к "предоставлению сервисов" и введением всяких DPI - что, оно не ломало всё полностью внутри их продуктов? В общем, это уж точно не аргумент. А вот возможность массе софта использовать классический IP4 в локальных масштабах (например, серые сети), и при этом выходить в мир, кто умеет, без двойного стека - это очень вкусно.

Вендору легче будет держать отдельный RIP/FIB, чем ковырять уже давно вылизанное.

Не легче, извини. Просто представь себе это внутри железяки, с конкретными протоколами.

Я не увидел в твоем подходе вообще ничего, что кардинально отличалось бы от подхода IPv6. Кроме размера адреса и вроде как какого-то удобства для разработчиков софта.

Никто не будет держать два паралельных интернета без взаимодоступности. Ни контентщики, ни сервисники. Все равно это все вырождается в дуалстек, нат и т.д. И, как следствие, тем же migration technics, поторые применяются для IPv6. В которых, кстати, какого-то rocket science нет.

Вариант Павла _не_ требует dual stack. Перечти ещё раз внимательно, если не видишь, почему. Местами задвоение есть, да. Начиная с DNS (вот уж где поле непаханое извращений). Но оно будет видно только технарям. Сейчас же проблема видна любому юзеру. -netch-

Mon, Feb 02, 2015 at 09:19:35, anton wrote about "Re: [uanog] Re: [uanog] Белые IP Freenet/O3":

...

...

Ну то есть, ты предлагаешь кусок адреса засунуть в ip options? Очень плохая идея.

Аргументируй, пожалуйста. Место в номерах опций есть. Насколько я понял RFC791, опции обязательны к пониманию всеми участниками, то есть пакет не пройдёт дальше раутера, который такое не знает; то есть, неправильной интерпретации адреса не будет. Что ещё не так?

Именно это не так. Тут и ломается наша совместимость.

Ещё раз. Если сторона не умеет новые адреса, то она не будет распознавать пакет. Так? Так это не "ломается совместимость", это "не умеет новое", и это совершенно нормально в данной ситуации.

...

Вопрос цены обработки в раутерах я тут не рассматриваю, он очевиден и не в пользу варианта Павла, но о нём речь не шла.

Я думал, мы комплексно пытаемся подойти к проблеме :-)

Именно. В чём ты видишь ещё проблему, кроме банальности, что старая собака не обучится новому трюку?

...

Есть совместимость в пределах старых возможностей и адекватная реакция на использование новых. Это и называется корректной обратной совместимостью.

Значит мы по-разному понимаем совместимость. Если хост А не понимает options хоста В, они не совместимы.

Извини за прямоту, ты вообще пробовал в выражении "обратная совместимость" обратить внимание не только на последнее слово? ;) Или ты надеешься на магическую укладку 64 бит в 32 без потерь? ;)

...

...

Вендору легче будет держать отдельный RIP/FIB, чем ковырять уже давно вылизанное.

Не легче, извини. Просто представь себе это внутри железяки, с конкретными протоколами.

Ну вот я представил. И представил себе логику RIB/FIB lookup. Не сходится у меня картинка.

Что именно не сходится? Давай подробнее. Вот у нас есть 64-битное поле для лукапа, там, где было 32-битное. Вот у нас укладка значений в него, которая кладёт нули в старшую часть, если не задано расширение адреса. Вот лукап, в зависимости от свойств архитектуры, 1 или 2 чтения из памяти. И что принципиально меняется, кроме расширения до 3 полей в длинной записи, где этих полей (если используется комбинированный FIB стиля CEF) штук 20-30?

...

Вариант Павла _не_ требует dual stack. Перечти ещё раз внимательно, если не видишь, почему. Местами задвоение есть, да. Начиная с DNS (вот уж где поле непаханое извращений). Но оно будет видно только технарям. Сейчас же проблема видна любому юзеру.

Без dual stack мы лишаем коннективити старые хосты и новые. Это никому не надо.

Что ты имеешь в виду? Если оба адреса короткие, то пакеты пройдут по всей цепочке без проблем. Если хотя бы один длинный, то последствия для коннективити ровно такие же, как сейчас в случае IP4/IP6, но не нужно держать два стека со всеми последствиями этого в виде двух наборов IP блоков, двух сервисов раздачи адресов, двух комплектов настроек файрволлов, и т.д.

Даже не беря юзеров (99% из которых абсолютно плевать, чо там внутри, они мыслят категорией "сайт не грузиццо"). Возьми внутренние системы оператора, которые работают между собой по каким-то east-west, north-south протоколам. Нам надо будет либо: а) делать апдейт всего и сразу б) делать dual stack c) строить новую систему

Выбери самый простой и дешевый вариант :-)

Я как раз и описываю самый простой и дешёвый вариант. Твои же варианты требуют как минимум перевода. Чем отличается (c) от остальных вариантов?

То есть, в какой-то момент нам надо будет на определенных элементах держать стек, который понимает и новое, и старое. Что это, как не dual stack?

Нет, это не dual stack. Dual это IP4/IP6, когда стеки независимы. -netch-

hi, Sun, Feb 01, 2015 at 21:46:00, anton wrote about "[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3":

А в IPv6, например, нет бродкаста. Переработана фрагментация. Нативный ipsec.

Знаешь, у тебя тут были разные аргументы, но вот именно этот набор совершенно неадекватен. "Нет бродкаста" - ничего хорошего в этом нет. Наоборот, резко выросли требования к сетевым адаптерам: если раньше минимальному из них хватало режима "ловим собственный MAC, а если хочется странного, то включаем promisc" для 99% случаев, то сейчас для эффективной работы нужен ещё как минимум один фиксированный адрес для мультикаста собственного IP. Ну или promisc, на котором вообще любой мусор ловить. Аналогично, резко вырастают требования к свичам - или они работают со всеми мультикастами как бродкастами, или начинают поддерживать как минимум IP6-аналог IGMP snooping. "Переработана фрагментация" - единственное слово, которым я могу назвать обязательный отказ от фрагментации в раутерах, это - лицемерие. Больше же ничего принципиально не изменилось. "Нативный ipsec" - вообще техническая чушь, он ничуть не более "нативный", чем в IP4. В обоих случаях промежуточный заголовок и payload. Средства управления (в которых основная соль в ipsec) от этого лучше не становятся, алгоритмы IKE - тоже, и бредовость их реализации не уменьшается. Есть только два однозначно положительных свойства нового стандарта: 1. Неучастие hop limit в контрольной сумме. 2. Увеличение минимального требуемого link MTU с 68 до более полезного значения (1280, может, завышено, но вообще хотелось от 500 для всех случаев). Всё остальное - спорно. -netch-

Sun, Feb 01, 2015 at 21:08:00, anton wrote about "[uanog] Re: [uanog] Re: [uanog] Белые IP Freenet/O3":

...

...

Как ты будешь мерять MTU в транспортной сети между двумя хостами? Кто будет фрагментировать? Что произойдет, если icmp не ходит? Ничего не изменится по отношению к тому, как оно есть сейчас. А как оно есть сейчас?

Вот пример. При одном и том же MTU 1500, если анализировать TCP пакеты, можно увидеть два типичных варианта: MSS 1460 и 1448. Первое возникает при отсутствии опций увеличения размера окна свыше 64K - что типично для всяких мелких железяк прошлого поколения, до тотальной линуксизации и выхода в режим "процессором для embedded называется 32-битный процессор" - отказа широких вендорских масс работать на AVR/PIC/etc. Второе - при современной ОС на 32/64-битном железе, когда добавляются такие опции. Прикладное же программирование вообще не меняется. Конечно, можно предположить, что где-то в Пенджабе очередной Сутрапохмел Абдулкумар сделает Первый Великий Ляп работы с TCP - предположит, что тот сохраняет границы порций по send(), и будет посылать по 1460 - но даже среди таких это будет очень редкий случай.

Из-за этой проблемы (отчасти) фрагментацию в IPv6 переложили на плечи хостов.

Эта проблема там ни при чём. Отказ от фрагментации на раутерах, это неоднократно писалось прямым текстом, вызван двумя причинами: 1. Разгрузка процессоров раутеров. По этой же причине убрали hop limit (бывший TTL) из контрольной суммы IP заголовка: если пакет побьётся, целостность этого поля непринципиальна, а не-пересчитывать каждый раз контрольную сумму, это - величайший выигрыш. 2. Избавление от проблем последовательной фрагментации. Пример: если есть промежуточные линки с MTU 1400 и где-то за ним с 1300, то в IP4 без DF на финальный хост придёт 1300+100+100, а не 1300+200 (для ясности, размер fragment header не считаю). Само по себе это никак не лечит проблемы MTU и фрагментации, разве что способно методом шоковой терапии заставить всех написать правильную реализацию. Но, судя по тому, что в 2015 году продолжаются проблемы с негенерацией ICMP needfrag в чуть нетривиальных конструкциях типа "IPIP внутри IPSec", руки писателей стеков от этого не выпрямились (наблюдали с месяц назад на Linux). Генерацию на конечных хостах чуть улучшили - теперь она умеет, например, сама пробовать уменьшать MTU, если перестали проходить пакетики; но, с учётом скорости реакции этого механизма, для чего-то с требованием оперативности быстрее минуты лучше писать реализацию самому поверх UDP, чем полагаться на эти механизмы.

Относительно к IPv6, с которого все началось. Вы реально думаете, что они настолько упоротые, что не увидели "простого и элегантного" решения, в котором "все решается само"?

Да, они упоротые. Потому что реально ничего вообще не продумывалось. В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было параллельно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) - 64 на глобально уникальный и 64 на локально уникальный. Одно это уже способно однозначно показать, в каких безумных эмпиреях и воздушных замках витали авторы предложения. Обсуждение вариантов молча (письменных свидетельств нет) завершилось на 128 битах после того, как некто Daniel L. McDonald из рассылки SIPP (оно тогда так называлось) 07.07.1994 написал следующие слова: ===== Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues of fixed length addresses before. My biggest beef with variable length addresses is the issue of maintaining additional state or taking additional time to parse an address whose length I don't know at the start.<...> Parsing addresses is a problem all along the path (both network hops, and within each system) an IPng datagram takes. Both routers and end-systems have to parse addresses, at least to the point of finding a fast path. Our implementation experience has shown us that variable length addresses adds a whole new layer of complexity to things such as: * Routing lookups * User interface issues * Storage requirements * Address parsing (for lookups, incoming packets, etc.) and everyone's favorite * Application programmer level backward compatibility ===== С этого момента предложение на 64 бита _молча_ исчезло, оставив в силе предложение с двумя уникальными адресами(!!!!!), и только через некоторое время оно преобразовалось в нынешний вариант - когда рекомендацией для младшей половины является EUI-64, и оно уникально в пределах фиксированной старшей половины, а не вообще; но именно EUI-64 происходит из идеи "младшая половина уникальна сама по себе". Вся эта безумная траектория предложений и показывает, что реального рассмотрения альтернатив НЕ БЫЛО. "Узкая группа ограниченных людей" (tm) варилась в своём соку, занимаясь вопросами, которые никому больше не были интересны, и выдвигала предложения без всякого практического обоснования. Более того, старт работы этой группы начался ещё в 92-м году, когда был в ходу классовый раутинг, на котором адреса должны были закончиться не позже 96-го; введение безклассового оттянуло конец IP4 на 20 лет, но это сделала ДРУГАЯ группа, а не та, которая строила воздушные замки вокруг SIP -> SIPP -> IPv6. И, да, переход на безклассовый раутинг был реформой примерно того же типа, что предлагает Павел, хотя заметной только для сетевиков; писатели прикладного софта её не заметили, а вот писателям сетевого пришлось переделать чуть менее чем всё. Не знаю, работал ли ты тогда в телекоммуникациях, но можешь погуглить по словам "два раутера Bay Networks, BGP, RIPv1 и падение всего интернета", ветераны ещё должны помнить - эта история как, извините за длинное слово, квинтэссенция всех проблем этого перехода. -netch-

Hi Valentin,

Вся эта безумная траектория предложений и показывает, что реального рассмотрения альтернатив НЕ БЫЛО. "Узкая группа ограниченных людей" (tm) варилась в своём соку, занимаясь вопросами, которые никому больше не были интересны, и выдвигала предложения без всякого практического обоснования. Более того, старт работы этой группы начался ещё в 92-м году, когда был в ходу классовый раутинг, на котором адреса должны

Спасибо. Я примерно это и хотел сказать. К сожалению, никакой алтернативы разработке протоколов и правил "узкими группами ограниченных людей" мне неизвестно. Т.е. да, есть "они упоротые" к-рые что-то делают и ещё немного тех, кто тихонько возмущаются. ("По-моему так") Я совершенно согласен, что dual-stack - это ужасно. И отсутствие обратной совместимости сильно мешает. В Пашином варианте, думаю, было бы много проблем от этой обратной совместимости, но наверное оно того бы стоило... Думаю, в 92-м году это было совершенно неочевидно и/или вообще задачи были не те. -- Mike Если человек делится яблоками, значит, у него есть яблоки. Если человек делится идеями, значит, у него нет яблок.

Hi Andrii,

Не согласен. В начале 90-х все что говорят Паша и Валентин уже тоже обсуждалось. Но... принцип открытого публичного обсуждения был нарушен в пользу симулякра "титулованные эксперты придумают лучше" и кулуарных договоренностей между ними.

А можно подробнее? В эту ipngwg пускали не всех?

Но параллельно в уйме рассылок, newsgroups и форумов вроде этой ВСЕ ПЕРЕЧИСЛЕННОЕ Пашей и Валентином НЕОДНОКРАТНО ВЫСКАЗЫВАЛО МНОЖЕСТВО РАЗНЫХ ЛЮДЕЙ. И кстати и на очных мероприятиях типа конференций тоже.

Ну и почему это делалось параллельно а не там, где надо? -- Mike Портняжный взгляд на жизнь: конечно, коротковата, но если немного отпустить...

Hi Andrii, Я думаю, что все wg открыты для всех желающих. И если это так, мне трудно ругать тех, кто не поленился и таки записался в ту группу и что-то придумал.

...

А можно подробнее? В эту ipngwg пускали не всех?

Если честно, я просто не помню уже. Припоминаю, что речь шла о группе, у которой был явный оргкомитет, который в свою очередь решал, кто включен в группу.

Надо архивы смотреть.

...

Ну и почему это делалось параллельно а не там, где надо?

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

Вот показало.

-- Mike

Dual Stack ужасен тем, что он добавляет второй геморрой (который скоро станет уже обязательным), не вылечивая первый: без v4 подключение к Интернету есть и будет фактически неработоспособным с точки зрения юзера. On 02.02.15 12:25, Mike Petrusha wrote:

Hi Valentin,

...

Вся эта безумная траектория предложений и показывает, что реального рассмотрения альтернатив НЕ БЫЛО. "Узкая группа ограниченных людей" (tm) варилась в своём соку, занимаясь вопросами, которые никому больше не были интересны, и выдвигала предложения без всякого практического обоснования. Более того, старт работы этой группы начался ещё в 92-м году, когда был в ходу классовый раутинг, на котором адреса должны

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

Т.е. да, есть "они упоротые" к-рые что-то делают и ещё немного тех, кто тихонько возмущаются. ("По-моему так")

Я совершенно согласен, что dual-stack - это ужасно. И отсутствие обратной совместимости сильно мешает. В Пашином варианте, думаю, было бы много проблем от этой обратной совместимости, но наверное оно того бы стоило...

Думаю, в 92-м году это было совершенно неочевидно и/или вообще задачи были не те.

On Mon, Feb 02, 2015 at 04:18:36PM +0100, Mike Petrusha writes:

"Facebook IPv6-only internal network" - не пример "работоспособности с точки зрения юзера" без dual stack?

По-моему, это гандикап такой. Один из способов заявить о себе и обратить на себя внимание. Боюсь представить, на сколько граблей они наступили и сколько кейсов открыли. Некоторые и на Эверест взбираются, но это ж не значит, что туда проложена удобная и полезная дорога. :) -- Паша.

Mon, Feb 02, 2015 at 17:11:53, mp wrote about "Re: [uanog] Белые IP Freenet/O3":

10/8 они израсходовали,

Можно ссылку? А то или полная фантастика, или (скорее всего) они не хотели использовать любые размеры сетей, кроме октетных (/24, /16). При такой специфике человеческого фактора можно было, да, и в десятку не влезть. В Massol'е мы с таким столкнулись у клиента - вместо нормальной структуры сети пришлось изобретать комитетских верблюдов только потому, что старший админ клиента сказал "мои люди не поймут эти ваши /22".

переписывать внутренний софт нужно было в любом случае, решили уж так, чтоб "навсегда". Думаю, что потом обнаружили, что масштаб переписывания от смены на IPv6 стал совсем не тот...

Масштаб чего?

Ну а что делать с внутренней сетью на к-рую не хватило (может не хватить) IPv4-адресов (приватных)?

Организовать по-нормальному, ящетаю. -netch-

Mon, Feb 02, 2015 at 17:12:23, me wrote about "[uanog] Re: [uanog] Белые IP Freenet/O3":

...

Можно ссылку? http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv...

80/128 им неэкономно, а 80/2**64 экономно. Ясно, спасибо:)

Я это вижу примерно следующим образом: Перенумеровывать сеть и переписывать софт, в который годами закладывалась неявная логика (каждую стойку выделяется /24, на каждый кластер /X, etc) - долго и неинтересно. Неинтересную работу никто не любит. Мигрировать на IPv6 - долго, но интересно. Также это можно делать постепенно, при этом можно находить (и, в случае с open source, исправлять) баги в софте. Об этом можно рассказывать на конференциях и развивать имидж компании, инвестирующей в технологии и прокладывающей всем остальным дорогу в будущее. В компанию с таким имиджом проще набирать на работу хороших инженеров за разумные деньги.

Да, "интересно" действительно ключевое слово. Покрывает, похоже, 90% всемирной мотивации перехода на IP6 :) -netch-

On Mon, Feb 02, 2015 at 09:28:37PM +0100, Mike Petrusha writes:

...

...

...

Ну а что делать с внутренней сетью на к-рую не хватило (может не хватить) IPv4-адресов (приватных)? Организовать по-нормальному, ящетаю. Я это вижу примерно следующим образом: Перенумеровывать сеть и переписывать софт, в который годами закладывалась неявная логика (каждую стойку выделяется /24, на каждый кластер /X, etc) - долго и неинтересно. Неинтересную работу никто не любит. Мигрировать на IPv6 - долго, но интересно.

Ну а куда его переписывать? У них в каждом /24 80 адресов использовано, т.е. 30%.

Вот, кстати, прикольно. Для получения белых IP нужно было обосновать 50% использования в течение года с предъявлением уникальных mac-адресов (в разное время по-разному, но смысл такой). А для серых сетей, если в блоке из 16 миллионов IP находятся десятки тысяч компов - то это называется "адреса закончились". :) И ещё скажу крамольную мысль. Если внутренняя сеть такая большая, действительно ли каждый адрес в ней должен быть уникален? Ведь задача, чтобы любой сервак и любой свич в мире был доступен откуда угодно, явно не ставится. По-моему, вполне нормально сначала попасть на jump server в нужной стране, оттуда на другой jump server в датацентре, и оттуда уже на конкретный сервак за каким-нибудь балансером. Уникальные серые IP должны иметь внутренние сервисы, единые для всей большой компании - а для таких, предполагаю, /16 с головой хватит. От того, что какой-нибудь свич в Дублине имеет такой же mgmt IP, как какой-нибудь другой свич в Сан-Франциско, никакой OSPF с ума не сойдёт, потому что не должно быть единого OSPF на все эти mgmt networks.

Тут вопрос другой - если с IPv6 эта сеть живёт, будучи оторванной от всего IPv4-интернета, могли бы её оставить на IPv4 и тоже так оторвать, чтобы использовать внутри все IPv4-адреса, а не только приватные.

По-моему, в таком решении заложено множество мин. Шлёшь, например, syslog на внутренний адрес логсервера, но роутер упал, маршрут на сетку отвалился, и логи ушли по дефолту наружу. Понятно, конечно, что никакого "дефолта наружу" быть не должно, но всё-таки такая конфигурация мне кажется граблеопасной. -- Паша.

2015-02-03 20:39 GMT+02:00 Mike Petrusha :

...

Шлёшь, например, syslog на внутренний адрес логсервера, но роутер упал, маршрут на сетку отвалился, и логи ушли по дефолту наружу.

Джентльмены, мне даже неловко спрашивать, но ВЫ ЧО?! как это "логи ушли по дефолту"????

On Tue, Feb 03, 2015 at 09:00:32PM +0200, Andrii Stesin writes:

2015-02-03 20:39 GMT+02:00 Mike Petrusha :

...

...

Шлёшь, например, syslog на внутренний адрес логсервера, но роутер упал, маршрут на сетку отвалился, и логи ушли по дефолту наружу.

Джентльмены, мне даже неловко спрашивать, но ВЫ ЧО?! как это "логи ушли по дефолту"????

Да вот как Спринт принял весь "релком" из канала 19200, или как bgp fullview в ospf продистрибьютилось, так и логи по дефолту. :-D Факапы бывают, это неизбежно, вопрос лишь в том, что последствия любой одной ошибки не должны быть катастрофическими. Как это давно известно в авиации. -- Паша.

On Tue, Feb 03, 2015 at 09:20:29PM +0200, Andrii Stesin writes:

2015-02-03 21:10 GMT+02:00 Pavel Gulchouck :

...

как bgp fullview в ospf продистрибьютилось

не было там никакого OSPF, то сильно умнО

Это я другую историю припомнил. :) -- Паша.

Tue, Feb 03, 2015 at 21:20:29, stesin wrote about "[uanog] Re: [uanog] Белые IP Freenet/O3":

...

как bgp fullview в ospf продистрибьютилось не было там никакого OSPF, то сильно умнО

Это таки другая история, из жизни LuckyNet. === cut here === Жил-был на edge раутере (с BGP fullview) redistribute map BGP->OSPF, прикрытый redistribute list'ом с deny any. В один сильно не прекрасный момент один из нокеров решил устранить лишнюю сущность в виде list'а.:) Тот из закрытого превратился в пустой и потому открытый. Дежурный удивлённо наблюдал как NAS'ы (которые были от 2511 до 5300) по очереди пропадали из видимости.:) Половина кошек просто перезагрузилась. Другая половина осталась в ROMMON'е, и канальщикам до конца дня была работа ездить по площадкам дёргать anykey. === end cut ===

был RIPv1 имени Gay Networks

Ну да, это я и вспоминал.

p.s. касаемо "катастрофических факапов в авиации" позволю себе напомнить историю когда люфтваффе внедрило http://en.wikipedia.org/wiki/Schr%C3%A4ge_Musik и англичане с амерами очень долго не могли понять, what the fuck is going on теряя самолеты и экипажи

Тоже красиво. Именно про такие вещи Мюллер говорил, что непрофессионала крайне сложно предугадать.:) -netch-

Tue, Feb 03, 2015 at 21:00:32, stesin wrote about "[uanog] Re: [uanog] Белые IP Freenet/O3":

...

...

Шлёшь, например, syslog на внутренний адрес логсервера, но роутер упал, маршрут на сетку отвалился, и логи ушли по дефолту наружу.

Джентльмены, мне даже неловко спрашивать, но ВЫ ЧО?! как это "логи ушли по дефолту"????

=== cut: man syslog.conf === · A hostname (preceded by an at (“@”) sign). Selected messages are forwarded to the syslogd(8) program on the named host. If a port number is added after a colon (‘:’) then that port will be used as the destination port rather than the usual syslog port. IPv6 addresses can be used by surrounding the address portion with square brackets (‘[’ and ‘]’). === end cut === и происходит это по UDP. Ну да, отсутствие ingress/egress filtering на границе - в принципе симптом кривых рук, но "забыл настроить" случается с каждым.:( -netch-

Mon, Feb 02, 2015 at 16:18:36, mp wrote about "Re: [uanog] Белые IP Freenet/O3":

...

Dual Stack ужасен тем, что он добавляет второй геморрой (который скоро станет уже обязательным), не вылечивая первый: без v4 подключение к Интернету есть и будет фактически неработоспособным с точки зрения юзера.

Чем NAT64 плох?

"Facebook IPv6-only internal network" - не пример "работоспособности с точки зрения юзера" без dual stack?

Однозначно нет. Там нет ничего такого, что должно ходить через границу мировых адресов через NAT или вообще напрямую, вместо этого сплошной ALG на границе. Юзера так не работают, им подавай браузер.:)

http://www.internetsociety.org/deploy360/resources/case-study-facebook-movin...

Все существенные подробности скрыты. Но они и не столь важны. -netch-

Им самое время начинать внедрять "Чебурашку". :-( 2015-02-03 23:52 GMT+02:00 Oleksandr V. Typlyns'kyi :

Yesterday Feb 2, 2015 at 18:34 Valentin Nechayev wrote:

...

...

Чем NAT64 плох?

"Facebook IPv6-only internal network" - не пример "работоспособности с точки зрения юзера" без dual stack?

Однозначно нет. Там нет ничего такого, что должно ходить через границу мировых адресов через NAT или вообще напрямую, вместо этого сплошной ALG на границе. Юзера так не работают, им подавай браузер.:)

...

http://www.internetsociety.org/deploy360/resources/case-study-facebook-movin...

Все существенные подробности скрыты. Но они и не столь важны.

Яндекс тоже внедряет: https://events.yandex.ru/lib/talks/380/ https://events.yandex.ru/lib/talks/1484/

-- WNGS-RIPE -- VEL-[RIPE|UANIC]

2015-02-04 10:51 GMT+02:00 Mike Petrusha :

...

Яндекс тоже внедряет: https://events.yandex.ru/lib/talks/380/ https://events.yandex.ru/lib/talks/1484/ Судя по слайдам 7-8 и тому, что говорится, похоже, что они "тоже" внутреннюю сеть IPv6-only сделали. Невероятно.

Это вероятно, однако удивительно... мне лично трудно представить инфраструктуру в которой в сумме 10/8 + 172.16/12 не хватит.

Hi Pavel,

Отсутствие обратной совместимости приводит к тому, что IPv6 не заменяет собой IPv4, а строится рядом с ним, параллельно и независимо.

Это утверждение справедливо только если IPv4 адресов хватило, чтобы рядом "стоять".

А значит, IPv6 не решает проблему дефицита IPv4-адресов

Естественно, нехватающие IPv4-адреса нельзя восполнить из IPv6. Это другой протокол, как уже и замечено. Так что проблема при нехватке IPv4 адресов получается другая - подключение через NAT. Соотв-но выбор между native IPv6 и NAT IPv4.

IPv4 будут необходимы сетевым ресурсам, пока будут оставаться IPv4-пользователи,

IPv4-only-пользователи вполне могут доступаться к IPv6-only-сетевым-ресурсам. Для этого есть другой NAT. [копия]

будут оставаться IPv4-пользователи, т.е. всегда.

Будут ли оставаться IPv4-пользователи (IPv4-only-пользователи) всегда? Наверное да. Будет ли это значить, что IPv6 отомрёт и будет всюду IPv4 NAT - не уверен. Вот, например пользователи с wap-browser'ами тоже будут оставаться всегда. И что-то wap-сайтов всё меньше и меньше.

А если IPv6 не решает глобальную проблему дефицита IPv4-адресов, но создаёт много проблем, зачем он вообще нужен?

Сам я в разработке протоколов участия не принимал, но тоже участвующими очень возмущён. Ещё вот писатели драйверов к ядру FreeBSD тоже меня очень возмущают- не могу узнать температуру материнки. Надо их там тоже всех запретить. [тоже шутка] -- Mike Скажите, у Вас в роду беременные были?

27.01.2015 14:12, Paul Arakelyan пишет:

On Sun, Jan 25, 2015 at 11:50:33PM +0200, Alexandr Baryshnyev wrote:

...

А вот зачем домашнему юзеру белый IP? Чтобы сервер у себя дома поставить? Так это на домашних тарифах запрещено практически у всех провайдеров.

Skype - без проброшенных портов файлы херово пролезают (зажата скорость сильно, они через третью сторону ползут). Торренты (да тот же апдейтер варгейминга). Сервер кемпер-страйка (и прочих игр) - врядли шо жрёт, но тоже надо порты. Или кто-то NAT с uPNP раздаёт?

Да, всё это так. Сетевые игры - вообще отдельная песня. Ну значит только покупка белого IP как дополнительной услуги, другие варианты малоэффективны для тех, кому и правда надо. Главное тогда, чтобы эта допуслуга была доступной, не грузила кошелёк юзера. Подобная эпопея была уже с запретом на выход 25-го порта по умолчанию. Это позволило значительно снизить вирусный спам трафик от юзеров, а подавляющее большинство юзеров этого даже не заметила, поскольку или вообще электропочтой не пользуются, или пользуются веб-почтой, или используют для отправки почтовый сервер провайдера. Ну а кто заметил - так тому быстренько и бесплатно открыли порт под его ответственность о нераспространению спама. Всё быстро утихло. Тут ещё одна интересная проблема есть. На данный момент у подавляющего большинства юзеров дома более одного устройства, требующего выход в инет. А это значит, что почти у всех уже стоят дома WiFi маршрутизаторы, которые тоже, о ужас, делают НАТ. Если ещё и провайдер НАТит, то выходит двойной НАТ и тут уж точно все возможные проблемы повылезают. -- Best regards, Alexandr B. Baryshnyev, e-mail: abb@abbon.net

Hi Max,

И что, от появления IPv6 у юзера начнет работать Skype, игрушки и воип клиенты, которые про этот самый IPv6 ваще ничего не знают?

Ну, когда-нибудь же начнёт :) Т.е. есть перспектива, в отличие от того, что не дружит с NAT :) -- Mike

Э - стоп. За НАТом домашней коробки - можно переписать. За любым, какой ни есть, провайдерским - без обязательной к исполнению спецификации "как это обязательно должно работать, иначе запрет эксплуатации" - не реально. On Fri, Jan 30, 2015 at 03:18:25PM +0200, Max Tulyev wrote:

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

On 30.01.15 14:59, Mike Petrusha wrote:

...

Hi Max,

...

И что, от появления IPv6 у юзера начнет работать Skype, игрушки и воип клиенты, которые про этот самый IPv6 ваще ничего не знают?

Ну, когда-нибудь же начнёт :) Т.е. есть перспектива, в отличие от того, что не дружит с NAT :)

-- Best regards, Paul Arakelyan.

Вот реально, 99% абонов белый айпи не только не нужен, но и вреден. Правильный нат большинство и не заметит вообще. А вот дьявол кроется в деталях. Например, а сколько таймаут сессии? Многие мобильщики ради экономии ресурсов натов ужимают его до нескольких секунд, причем о закрытии сессии не сообщают ни одной из сторон. В результате - постоянные баги с всеми сессионными сервисами начиная от скайпа и заканчивая чатом Фейсбука, и батарейка мобильного девайса съедается в несколько раз быстрее, чем при использовании оператора с хоть и динамическим, но реальником... И таких "детских болезней" операторов с CGN - вагон и маленькая тележка. P.S. Мы выдаем нашим абонам белую статику, если чо ))) On 25.01.15 23:31, Yuriy B. Borysov wrote:

Hi!

On Sun, Jan 25, 2015 at 11:26:51PM +0200, Alexandr Baryshnyev writes:

...

Правильно, белые IP продать налево, а юзерам серые раздавать. Белые сейчас столько стоят, что стрёмно юзерам на шару раздавать :). Тем более, что они им на самом деле и не нужны вовсе.

Спорное утверждение, про нужность.

Или это сарказм?

Ну так я же говорю 99% абонов, а не 100% ;) Но непродуманным НАТом 99% легко превращаются в 75-80%. On 26.01.15 11:33, Mike Petrusha wrote:

Hi Max,

...

Вот реально, 99% абонов белый айпи не только не нужен, но и вреден.

А как же старая история с "вы уже скачиваете один файл с rapidshare" и с баном по IP на форумах, игровых серверах и т.п.?

Today Jan 25, 2015 at 23:30 Yuriy B. Borysov wrote:

On Sun, Jan 25, 2015 at 10:46:19PM +0200, Vasiliy P. Melnik writes:

...

А что мешает им позвонить и спросить ?

Написал им в саппорт, но пока ответа нет. Решил уточнить у коллег, может кто-то тоже заметил.

http://o3.ua/home/dop_uslugi/ipadress/ -- WNGS-RIPE

Today Jan 26, 2015 at 00:12 Yuriy B. Borysov wrote:

Hi!

On Mon, Jan 26, 2015 at 12:03:42AM +0200, Oleksandr V. Typlyns'kyi writes:

...

...

Написал им в саппорт, но пока ответа нет. Решил уточнить у коллег, может кто-то тоже заметил.

...

http://o3.ua/home/dop_uslugi/ipadress/

Это на данный момент. Но не совсем ясно, с какого времени действуют данные условия.

Когда точно началось не скажу, но до меня это "счастье" добралось в мае.

Дело в том, что условия изменились как-то незаметно. Уведомления в почту не приходило, беглое чтение сайта тоже не показало такой новости.

В то время ещё на сайте писали, что будут работы по "оптимизации" и нужно включить DHCP. Про "серые" адреса и NAT не писали.

Собственно заметил случайно. Перестал работать vpn (pptp), сервера различные (cisco/mpd), ip и страны тоже. Возможно связи и нет. Просто совпало. А может просто натилка не умеет корректно натить pptp.

Да - их NAT pptp не пропускает. -- WNGS-RIPE

На тот момент когда я подключался, это было по дефолту, я уже не помню подробностей. Или только с дорогими тарифными планами (я подключался на верхний, позднее понял шо оно мне без пользы, и перешел на какой-то из мелких). 2015-01-26 10:57 GMT+02:00 Yuriy B. Borysov :

Hi!

On Mon, Jan 26, 2015 at 10:54:54AM +0200, Andrii Stesin writes:

...

У меня freenet и белый IP прибит гвоздями на моем роутере. Если не начали его NAT-ить на бордерах(?), то ничего не поменялось.

Это заказывалось как отдельная услуга? Или какой-то стандартный тариф?

Спасибо!

-- WBR, Yuriy B. Borysov YOKO-UANIC | YOKO-RIPE

Ну вот у меня пока работает, поменять с белого на серый не могли потому что рули от роутера у меня. Другой вопрос что могли на старые ранее "белые" адреса втихаря поставить NAT и таким образом сделать их "серыми"... но это ж надо быть умным, не? ;)

Today Jan 26, 2015 at 21:38 Andrii Stesin wrote:

Ну вот у меня пока работает, поменять с белого на серый не могли потому что рули от роутера у меня. Другой вопрос что могли на старые ранее "белые" адреса втихаря поставить NAT и таким образом сделать их "серыми"... но это ж надо быть умным, не? ;)

А им и не нужно менять. После "оптимизации" со старым статическим IP ничего тупо не работало. -- WNGS-RIPE

А там маленьким шрифтом в конце написано - мегабайт интернета 10 гривен, в итоге за 200 метров трафика содрали 2000 грн Ну да - можно спорить, а можно забить 26 января 2015 г., 22:53 пользователь Andrii Stesin написал:

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