03.02.2011, в 7:23, Valentin Nechayev написал(а):

Thu, Feb 03, 2011 at 18:19:32, snar wrote about "[uanog] Изя всё.":

...

The IANA IPv4 registry has been updated to reflect the allocation of five /8 IPv4 blocks: one to each RIR, in February 2011. You can find the updated IANA IPv4 registry at:

Пора брать в руки оружие и экспроприировать экспроприаторов.

For example, you can pry these only from HP dead hands :) 015/8 Hewlett-Packard Company 1994-07 LEGACY 016/8 Digital Equipment Corporation 1994-11 LEGACY

On Sat, Feb 05, 2011 at 02:00:16AM +0200, Andrew Stesin wrote:

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

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

2011/2/5 Dmitry Kohmanyuk

...

03.02.2011, в 7:23, Valentin Nechayev написал(а):

...

Thu, Feb 03, 2011 at 18:19:32, snar wrote about "[uanog] Изя всё.":

...

The IANA IPv4 registry has been updated to reflect the allocation of five /8 IPv4 blocks: one to each RIR, in February 2011. You can find the updated IANA IPv4 registry at:

Пора брать в руки оружие и экспроприировать экспроприаторов.

For example, you can pry these only from HP dead hands :)

015/8   Hewlett-Packard Company 1994-07         LEGACY 016/8   Digital Equipment Corporation   1994-11         LEGACY

-- ------------------------------------------------------------------------------- Vasiliy P. Melnik VPM-RIPE, VPM-UANIC

Sat, Feb 05, 2011 at 10:37:50, gul wrote about "Re: [uanog] Изя всё.":

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Некоторые блоки /8 совсем не используются.

А под что зарезервирован блок 240.0.0.0/4? Наверное, его можно разрезервировать?

Угу. Подкорректировав все сетевые стеки, на что уйдёт ещё 15 лет. Вообще, единственный рабочий сейчас вариант (хоть и небыстрый) - устроить свободный рынок адресных блоков, с налогом на владение (например, 1% рыночной стоимости соответствует мировой традиции по недвижимости). Лёгкую дифференциацию по размеру (чтобы росло чуть медленнее количества адресов) - для уменьшения количества анонсов (или их числить отдельно) и порядок... (Я на 110% уверен, что это обсуждалось в IANA/RIRs/etc. и такое предложение было в числе рассмотренных, но ещё не выдвигалось как основное) -netch-

И убедить всех вендоров переписать софт? ;) Maxim Tuliuk On 5 Feb 2011, at 09:37, Pavel Gulchouck wrote:

On Fri, Feb 04, 2011 at 02:27:17PM -0800, Dmitry Kohmanyuk writes:

DK> 03.02.2011, в 7:23, Valentin Nechayev написал(а):

...

...

Thu, Feb 03, 2011 at 18:19:32, snar wrote about "[uanog] Изя всё.":

...

The IANA IPv4 registry has been updated to reflect the allocation of five /8 IPv4 blocks: one to each RIR, in February 2011. You can find the updated IANA IPv4 registry at:

Пора брать в руки оружие и экспроприировать экспроприаторов.

DK> For example, you can pry these only from HP dead hands :)

DK> 015/8 Hewlett-Packard Company 1994-07 LEGACY DK> 016/8 Digital Equipment Corporation 1994-11 LEGACY

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Некоторые блоки /8 совсем не используются.

А под что зарезервирован блок 240.0.0.0/4? Наверное, его можно разрезервировать?

-- Паша.

Кстати, в JUNOS можно. Начиная с 9.6: * Class E addresses*---The JUNOS Software now allows Class E addresses to be configured on interfaces. To allow Class E addresses to be configured on interfaces, remove the Class E prefix from the list of martian addresses by including the[edit routing-options martians 240/4 orlonger allow]configuration statement. http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-co... =) Только это все равно ничего не меняет. 05.02.2011 13:09, Valentin Nechayev пишет:

Sat, Feb 05, 2011 at 11:26:16, gul wrote about "Re: [uanog] Изя всё.":

...

...

...

А под что зарезервирован блок 240.0.0.0/4? Наверное, его можно разрезервировать? VN> Угу. Подкорректировав все сетевые стеки, на что уйдёт ещё 15 лет. А как сетевые стеки на него сейчас реагируют? Как на нечто невозможное. Кажется, только некоторые Unix'ы нормально воспринимают этот сегмент как ещё один unicast.

-netch-

-- Best regards, Egor Zimin

Hi Andrew,

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

Боюсь, ничего такого не произойдет до того, как RIRы начнут выдвать по 1K адресов в руки, http://www.ripe.net/ripe/docs/ripe-509.html#----use-of-last----for-pa-alloca... А судя по http://www.apnic.net/community/ipv4-exhaustion/graphical-information там это настанет очень скоро. -- Mike

Hi Dmitry, Я думаю, рынок достаточно быстро засохнет, т.к. не сможет удовлетворить больших операторов.

Хочет или не хочет этого райп, а рынок адресов уже есть и сейчас он активизировался. На днях получил спам в аську: "IPv4 адреса заканчиваются. По этому есть еще время купить блок адресов через наши резервы в Райпе http://....."

Так что пора им вспомнить старую поговорку "если процесс не остановить, надо его возглавить".

-- Mike Заряженному танку в дуло не смотрят.

On Mon, Feb 07, 2011 at 09:22:53AM -0800, Volodymyr Yakovenko wrote:

Панове!

Так радоваться надо, и на нашу улицу пришел праздник, чем плотнее безголовые СМИ нагнетут глупой шумихи, тем больше будет работы вскякой и разной для сетевых инженеров :-) А ля проблема 2000 года в сетевой профиль :-)

Мьсе не понимает :( Сетевые инженеры на backbone'ах ipv6 уже давным-давно подняли. А короёбочки-"рОутеры" с поддержкой IPv6 только-только появляться начали. Я уже не говорю про короёбочки с SIPv2 over IPv6, которых я вообще пока в природе не видел. Не, сетевым инженерам, конечно, тоже светят веселые годы, но саппорту, как обычно, будет веселее... -- In theory, there is no difference between theory and practice. But, in practice, there is.

2011/2/7 Alexandre Snarskii :

On Mon, Feb 07, 2011 at 09:22:53AM -0800, Volodymyr Yakovenko wrote:

...

Панове!

 Так радоваться надо, и на нашу улицу пришел праздник,  чем плотнее безголовые СМИ нагнетут глупой шумихи,  тем больше будет работы вскякой и разной для сетевых  инженеров :-) А ля проблема 2000 года в сетевой профиль :-)

Мьсе не понимает :( Сетевые инженеры на backbone'ах ipv6 уже давным-давно подняли.

Ммм ... Саша, у вендора на букву J все еще много проблем с работой IPv6 in general и в части транспорта оного поверх MPLS TE backbone in particular. Через сколько кварталов после выхода MX3D железа J выпустил JunOS, который официально поддерживал v6 forwarding? Это я все к тому, что поддержка v6 со стороны вендоров все еще баловство и багодром, в какомто виде это все запускают, но реальных объемов траффика там пока нет. Вот как он появится - все станет сильно веселее :-)

А короёбочки-"рОутеры" с поддержкой IPv6 только-только появляться начали. Я уже не говорю про короёбочки с SIPv2 over IPv6, которых я вообще пока в природе не видел.

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

-- Regards, Volodymyr.

On Mon, Feb 07, 2011 at 11:18:02AM -0800, Volodymyr Yakovenko wrote: [dd]

...

Мьсе не понимает :( Сетевые инженеры на backbone'ах ipv6 уже давным-давно подняли.

Ммм ... Саша, у вендора на букву J все еще много проблем с работой IPv6 in general и в части транспорта оного поверх MPLS TE backbone in particular. Через сколько кварталов после выхода MX3D железа J выпустил JunOS, который официально поддерживал v6 forwarding?

Зато у этого вендора все хорошо на legacy платформах и межвендорная совместомость включается одним knob'ом и не требует перезагрузки всей коробки. В отличии от вендора C требуюшего онной по факту активации аппаратной коммутации. А про цирк с активацией второго af для vrf вообще вежливей будет промолчать.

Это я все к тому, что поддержка v6 со стороны вендоров все еще баловство и багодром, в какомто виде это все запускают, но реальных объемов траффика там пока нет. Вот как он появится - все станет сильно веселее :-)

В известном тебе ландшафте от вендора C с периодичностью в неделю зависает ipv6 enabled файрвол. А о синхронизации конфигурации пары Active/Standby узлов файрвола отказываются даже разговаривать. -- ZA-RIPE||ZA1-UANIC

Hello! Tue, Feb 08, 2011 at 09:32:16AM +0200, dmitry wrote:

Добрый день!

Судя по слайдам идет у них оно крайне хреново: за три месяца всего 1.5% абонентов активировали себе ipv6, и всего 0.15% реально получали адрес. Собственно, это отлично подтверждает тезис: "абоненту оно нах не нужно, пока все работает с IPv4". И пока оператор оставляет абоненту альтернативу так оно и будет.

Я думаю среднему абоненту абсолютно все равно IPv4 у него или IPv6, в случае, если у него нормально работает Интернет и все его сетевые приложения. Это нам с Вами не все равно и еще создателям контента :) P.S. Радует записанная в полном формате строка бэкрезолва для IPv6 :).

On Mon, Feb 07, 2011 at 09:17:46PM +0100, Maxim Tuliuk wrote:

...

Это смотря как внедрять: если "день Х настал и сегодня все будут на IPv6", то да - будут проблемы, а если step-by-step, то процесс идет, например: http://ripe61.ripe.net/presentations/128-MH-RIPE61-IPv6-XS4ALL.pdf

Best wishes, Maxim

2011/2/7 Alexandre Snarskii

...

On Mon, Feb 07, 2011 at 09:22:53AM -0800, Volodymyr Yakovenko wrote:

...

Панове!

Так радоваться надо, и на нашу улицу пришел праздник, чем плотнее безголовые СМИ нагнетут глупой шумихи, тем больше будет работы вскякой и разной для сетевых инженеров :-) А ля проблема 2000 года в сетевой профиль :-)

Мьсе не понимает :( Сетевые инженеры на backbone'ах ipv6 уже давным-давно подняли. А короёбочки-"рОутеры" с поддержкой IPv6 только-только появляться начали. Я уже не говорю про короёбочки с SIPv2 over IPv6, которых я вообще пока в природе не видел.

Возможно многим коробочкам с SIPv2 просто выпустят новые firmware. Хотя выгодней продать новые модели :)

...

...

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

-- In theory, there is no difference between theory and practice. But, in practice, there is.

-- Dmitry Kiselev

-- Best regards, Igor Kremez

Hi Valentin,

...

Это нам с Вами не все равно и еще создателям контента :) P.S. Радует записанная в полном формате строка бэкрезолва для IPv6 :). /me тоже посмеялся - его явно создавали до classless reverse, иначе сделали бы хотя б октетами (2 хексы).

Где читать про IPv6 classless reverse? -- Mike

Hi Valentin,

...

...

...

Это нам с Вами не все равно и еще создателям контента :) P.S. Радует записанная в полном формате строка бэкрезолва для IPv6 :). /me тоже посмеялся - его явно создавали до classless reverse, иначе сделали бы хотя б октетами (2 хексы).

Где читать про IPv6 classless reverse?

А разве я сказал, что он есть?;)) Хотя по идее резолверу должно быть пофиг, если в нём уже добавлено раскрытие CNAME для бэкрезолва, то v4/v6 будет одинаково раскрываться.

Ну ладно. Все равно, для v6 актуальнее *, а не CNAME. Провадер не может угадать mac адрес клиента. И нагенерить случаных left.right.provider.com на каждый адрес тоже не сможет. -- Mike

ipv4 - морально и физически устаревшая технология,

отличная технология, прекрасно работает, полностью стабильна и никуда в обозримом будущем не денется другое дело что сети массового абонентского ШПД гораздо проще и правильнее перевести на 6 версию и стыковать с 4 сетью через NAT тем самым все вопросы-то и решаются лет на 50 вперед

...

другое дело что сети массового абонентского ШПД гораздо проще и Любой NAT тут - диверсия.

Чем тебе не угодил NAT для миллионов домашних хомячков? с их микроволновками, телевайзерами и прочими IP-aware унитазами?

On Tue, Feb 08, 2011 at 03:08:33PM +0200, Andrew Stesin wrote:

...

...

другое дело что сети массового абонентского ШПД гораздо проще и Любой NAT тут - диверсия.

Чем тебе не угодил NAT для миллионов домашних хомячков? с их микроволновками, телевайзерами и прочими IP-aware унитазами?

с IPSec-ами и SIP-ами и прочими гулопостями. IPSec на динамическом айпишнике за нат-ом на Фре я так и не победил. А сколько еще подобных нюансов -- ------------------------------------------------------------------------------- Vasiliy P. Melnik VPM-RIPE, VPM-UANIC

Tue, Feb 08, 2011 at 15:08:33, stesin wrote about "Re: [uanog] Изя всё.":

...

...

другое дело что сети массового абонентского ШПД гораздо проще и Любой NAT тут - диверсия. Чем тебе не угодил NAT для миллионов домашних хомячков? с их микроволновками, телевайзерами и прочими IP-aware унитазами?

Ты путаешь NAT у хомячка дома (это как раз вполне разумно) и NAT у провайдера (как ты описывал). Первое - имеет смысл, второе - ты разве не помнишь, какие грабли были при работе через slirp? Всего-то 10 лет прошло, как его вынесли... -netch-

Ты путаешь NAT у хомячка дома (это как раз вполне разумно)

это разумно в случае 4 версии а в 6 просто наф не надо

NAT у провайдера (как ты описывал).

Только(!) исключительно(!) на стыке с 4-й сетью А так нафига, просто фильтры и никаких натов Помню, были какие-то, подробности забыл. Все эти негаразды - вопрос времени, и вас тоже полечат ;)

On Tue, Feb 08, 2011 at 03:31:40PM +0200, Valentin Nechayev writes: VN> Tue, Feb 08, 2011 at 15:26:15, stesin wrote about "Re: [uanog] Изя всё.":

...

...

Ты путаешь NAT у хомячка дома (это как раз вполне разумно) это разумно в случае 4 версии а в 6 просто наф не надо NAT у провайдера (как ты описывал). Только(!) исключительно(!) на стыке с 4-й сетью

VN> А теперь, внимание, правильный вопрос: НАФИГА??? VN> Нафига делать NAT с v6 внутри и v4 снаружи? Тогда проще сделать 10/8 VN> внутри, если наружу всё равно торчит NAT, а внутренние адреса никуда VN> не раутятся дальше этой же локалки. VN> NAT имеет смысл в одном из двух случаев: VN> * v4 внутри, v4 снаружи - адресов не хватает VN> * v4 внутри, v6 снаружи - внутренние звери не умеют v6 Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса? А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится. И это всё из-за того, что IPv6 разрабатывали в 1992-1995, когда и проблемы перехода выглядели иначе, да и сам IPv4 ещё не был повсеместно распространён. На мой взгляд, правильнее было бы расширить адресное пространство, сохраняя обратную совместимость (я об этом уже писал у себя в блоге), как asn16 расширили до asn32, или как time_t может быть 64-битным без всяких потрясений. Я не вижу в этом ни одной серьёзной проблемы, а при этом большинство проблем, которые возникают с IPv6, не возникли бы. В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга, с двумя разными адресами у пользователей и у сайтов, получать отдельные блоки адресов, практически полностью переписывать работу с сокетами в софте... И тогда через 2-5 лет (при поддержке вендоров) действительно мог бы состояться плавный переход на IPng, а на старые IPv4-адреса обращали бы внимания не больше, чем сейчас на шестизначные номера icq. А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили. -- Паша.

Hi, Статья в тему: There is no Plan B: why the IPv4-to-IPv6 transition will be ugly http://arstechnica.com/business/news/2010/09/there-is-no-plan-b-why-the-ipv4... -- //ShaD0w

On Tue, 8 Feb 2011 16:29:41 +0200 Pavel Gulchouck wrote:

On Tue, Feb 08, 2011 at 03:31:40PM +0200, Valentin Nechayev writes: VN> Tue, Feb 08, 2011 at 15:26:15, stesin wrote about "Re: [uanog] VN> Изя всё.":

...

...

...

Ты путаешь NAT у хомячка дома (это как раз вполне разумно) это разумно в случае 4 версии а в 6 просто наф не надо NAT у провайдера (как ты описывал). Только(!) исключительно(!) на стыке с 4-й сетью

VN> А теперь, внимание, правильный вопрос: НАФИГА???

VN> Нафига делать NAT с v6 внутри и v4 снаружи? Тогда проще сделать VN> 10/8 внутри, если наружу всё равно торчит NAT, а внутренние VN> адреса никуда не раутятся дальше этой же локалки.

VN> NAT имеет смысл в одном из двух случаев:

VN> * v4 внутри, v4 снаружи - адресов не хватает VN> * v4 внутри, v6 снаружи - внутренние звери не умеют v6

Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса? А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится.

И это всё из-за того, что IPv6 разрабатывали в 1992-1995, когда и проблемы перехода выглядели иначе, да и сам IPv4 ещё не был повсеместно распространён.

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

А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили.

-- With best regards, Gregory Edigarov

Tue, Feb 08, 2011 at 16:29:41, gul wrote about "Re: [uanog] Изя всё.":

Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса?

Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть и такие, которые дают сильно облегчённый доступ через v6 и обычный через v4. Разумеется, это не гугл и не новостной сайт.

А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится.

Пользователям, не поддерживающим v6, невозможно даже адресовать такой ресурс, поэтому такие варианты не рассматриваем. Можно обсуждать только доступ с v6 клиента на v4 сервер через NAT.

И это всё из-за того, что IPv6 разрабатывали в 1992-1995, когда и проблемы перехода выглядели иначе, да и сам IPv4 ещё не был повсеместно распространён.

Да, я об этом писал - что v6 начал разрабатываться ещё тогда, когда в v4 были классы сетей. И несколько принципиальных моментов основы v6 (как те же 128 бит адреса) вообще не имеют _никакого_ обоснования в основе.

На мой взгляд, правильнее было бы расширить адресное пространство, сохраняя обратную совместимость (я об этом уже писал у себя в блоге),

И как именно ты предлагаешь это сделать?

как asn16 расширили до asn32, или как time_t может быть 64-битным без всяких потрясений.

Плохие примеры. Для ASN32 расширение потребовало переделки софта всех участников, которые хотели полноценно видеть эти номера; а остальные получали какие-то огрызки, которые примерно соответствуют тому, как получилось с v4/v6. Расширение time_t до 64 бит сломало совместимость всех бинарных форматов, которые сохраняли время, и потребовало переходников с конвертерами. Ты не видишь его проблем только потому, что на самом деле мы этого переполнения не достигли. (Вообще, если отвлечься на time_t, то это клинически неудачная идея. Для представления времени точнее секунды, а это сейчас принципиально важно для большого количества случаев, мы должны хранить 12 байт, в то время как все альтернативные варианты хранят 8. Например, NT time имеет практически достаточную точность (100нс) и при этом представление 58 тысяч лет, если без знака. В Unix или храним микросекунды, тогда 12 бит теряется на ровном месте, или наносекунды, которые никто реально не умеет мерять на практически значимых платформах - 2 бита просто теряем, и ещё 10 забиваем мусором. Если мне придётся разрабатывать двоичный протокол с передачей времени, я там буду использовать именно NT time.)

Я не вижу в этом ни одной серьёзной проблемы,

Ты скажи, как именно ты собрался это реализовывать, и должны ли текущие реализации знать, что это уже не обычный IPv4 на 32 бита или нет, и как именно. Причём на всех уровнях. Например, как ты представляешь себе вместить 48 или 64 бита в struct sockaddr_in?

а при этом большинство проблем, которые возникают с IPv6, не возникли бы.

Слабо верится. Любое расширение - это несовместимость. IPv6 имеет одну принципиально важную основу: оно исходит из подхода "помирать, так с музыкой" - простите, "если ломать, то так, чтобы хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет". А что ты предложишь?

В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга,

Не отдельными? А какая цена замены 32->64?

с двумя разными адресами у пользователей и у сайтов, получать отдельные блоки адресов, практически полностью переписывать работу с сокетами в софте... И тогда через 2-5 лет (при поддержке вендоров) действительно мог бы состояться плавный переход на IPng, а на старые IPv4-адреса обращали бы внимания не больше, чем сейчас на шестизначные номера icq.

А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили.

См. IPv4-compatible и IPv4-mapped адреса. IPv4 включается в IPv6 как частный случай. Но протокол всё равно надо менять, ты в рамках того же не сможешь включить более 32 бит не меняя формат пакета. -netch-

2011/2/8 Pavel Gulchouck :

On Tue, Feb 08, 2011 at 10:00:14PM +0200, Valentin Nechayev writes: VN>  Tue, Feb 08, 2011 at 16:29:41, gul wrote about "Re: [uanog] Изя всё.":

...

...

Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса?

VN> Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть VN> и такие, которые дают сильно облегчённый доступ через v6 и обычный VN> через v4. VN> Разумеется, это не гугл и не новостной сайт.

У гугла вообще нет v6 адреса. Интересно, это принципиальная позиция или просто торможение.

http://www.google.com/intl/en/ipv6/ и начиная со слайда номер 12 это: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6...

А облегчённый доступ - ну понятно, биллинг-то на v6 не работает. :)

...

...

А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится.

VN> Пользователям, не поддерживающим v6, невозможно даже адресовать VN> такой ресурс, поэтому такие варианты не рассматриваем.

http://tools.ietf.org/html/draft-liu-behave-nat46-02 Всё очень грустно, да.

...

...

На мой взгляд, правильнее было бы расширить адресное пространство, сохраняя обратную совместимость (я об этом уже писал у себя в блоге),

VN> И как именно ты предлагаешь это сделать?

Детально я это не продумывал (потому что пока не верю в возможность реализации), но концептуально описал в соседнем письме.

...

...

как asn16 расширили до asn32, или как time_t может быть 64-битным без всяких потрясений.

VN> Плохие примеры. Для ASN32 расширение потребовало переделки софта VN> всех участников, которые хотели полноценно видеть эти номера; а VN> остальные получали какие-то огрызки, которые примерно соответствуют VN> тому, как получилось с v4/v6. Расширение time_t до 64 бит сломало VN> совместимость всех бинарных форматов, которые сохраняли время, и VN> потребовало переходников с конвертерами. Ты не видишь его проблем VN> только потому, что на самом деле мы этого переполнения не достигли.

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

Но когда я апдейчу у себя операционку, меня не особенно заботит возможная бинарная несовместимость - пересоберу, не проблема. И если мне скажут, что с 2013 года появятся новые адреса, которые будут поддерживаться только в FreeBSD 10, RedHat 16, Windows9 и JunOs 11 - для меня это вообще проблемой не будет. Я в любом случае не собирался приходить в 2013 год с имеющимся у меня сейчас Леопардом. Пользователи давно не удивляются, когда им говорят "этот сайт работает только с IE версии не ниже 7", и с пониманием относятся к необходимости апдейтов.

...

...

Я не вижу в этом ни одной серьёзной проблемы,

VN> Ты скажи, как именно ты собрался это реализовывать, и должны ли VN> текущие реализации знать, что это уже не обычный IPv4 на 32 бита или VN> нет, и как именно. Причём на всех уровнях. Например, как ты VN> представляешь себе вместить 48 или 64 бита в struct sockaddr_in?

Если кто-то работает с sockaddr_in по явным смещениям и ориентируется на его фиксированный размер вместо использования sizeof(sockaddr_in), тому придётся внести некоторые изменения в код. Примерно как тем, кто ориентировался на фиксированный тип time_t или int или long или size_t или off_t или прочих типов. Или на восьмибитность символа. Ничего - с utf-8 как-то смирились, так что смириться с изменением структуры sockaddr_in или in_addr тоже можно. По крайней мере, эти изменения существенно меньше, чем переписывание кода на IPv6 с совсем другими структурами и другим API.

...

...

а при этом большинство проблем, которые возникают с IPv6, не возникли бы.

VN> Слабо верится. Любое расширение - это несовместимость. VN> IPv6 имеет одну принципиально важную основу: оно исходит из подхода VN> "помирать, так с музыкой" - простите, "если ломать, то так, чтобы VN> хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет".

Я считаю, что IPv6 имеет противоположную основу. Оно не ломает IPv4. А ломать придётся.

VN> А что ты предложишь?

64-битных адресов хватит навсегда. Но эти адреса должны включать в себя IPv4 как подмножество. Тогда действительно будет возможен переход со старого на новое. 64-битный адрес - это u_int64_t, одно слово на 64-битных архитектурах, один регистр. 128-битный IPv6 - это массив, с которым обращаться гораздо сложнее. Разница существенная. Зачем нужен этот массив (и маршрутизация по flow label) - непонятно. Насколько с ним тяжело работать на больших скоростях - понятно.

...

...

В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга,

VN> Не отдельными? А какая цена замены 32->64?

Не более, чем, например, замена классического форвардинга на cef. И даже менее - там алгоритм другой, а тут просто изменяется кол-во битовых разрядов. Даже админ может не знать, пока специально не посмотрит, 32-битная или 64-битная таблица роутинга у его роутера, точно так же, как он может не знать, поддерживает ли его роутер asn32.

...

...

с двумя разными адресами у пользователей и у сайтов, получать отдельные блоки адресов, практически полностью переписывать работу с сокетами в софте... И тогда через 2-5 лет (при поддержке вендоров) действительно мог бы состояться плавный переход на IPng, а на старые IPv4-адреса обращали бы внимания не больше, чем сейчас на шестизначные номера icq.

А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили.

VN> См. IPv4-compatible и IPv4-mapped адреса. IPv4 включается в IPv6 как VN> частный случай.

IPv4 мапится в IPv6, но тоже не совсем без проблем. Например, если у меня только v6 и собственный dns, а у гугля только v4, то при обращении к гуглю я получу "host not found" - чтобы этого не было, я должен использовать специальный dns 6to4-гейта. А этот гейт мне ещё нужно где-то найти. Если я пользователь - понятно, спрашивать провайдера, а если я сам ISP, имеющий только v6-адреса, что делать?

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

И даже смешнее. Если всё-таки IPv6 начнёт вытеснять IPv4, то IPv4-адреса начнут освобождаться, дефицит исчезнет, а без дефицита IPv4 вновь получит преимущества перед IPv6. Классическая система лисы и зайцы, находящаяся в динамическом равновесии. Лисы никогда не смогут съесть всех зайцев.

VN> Но протокол всё равно надо менять, ты в рамках того VN> же не сможешь включить более 32 бит не меняя формат пакета.

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

-- Паша.

-- Regards, Volodymyr.

Tue, Feb 08, 2011 at 23:24:28, gul wrote about "Re: [uanog] Изя всё.":

...

...

Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса? VN>> Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть VN>> и такие, которые дают сильно облегчённый доступ через v6 и обычный VN>> через v4. VN>> Разумеется, это не гугл и не новостной сайт. У гугла вообще нет v6 адреса. Интересно, это принципиальная позиция или просто торможение. А облегчённый доступ - ну понятно, биллинг-то на v6 не работает. :)

Про гугл тут уже ответили, а при чём тут биллинг - я не понял.

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

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

Угу. И данные, записанные в старой версии, тебе не нужны. ;)

И если мне скажут, что с 2013 года появятся новые адреса, которые будут поддерживаться только в FreeBSD 10, RedHat 16, Windows9 и JunOs 11 - для меня это вообще проблемой не будет. Я в любом случае не собирался приходить в 2013 год с имеющимся у меня сейчас Леопардом. Пользователи давно не удивляются, когда им говорят "этот сайт работает только с IE версии не ниже 7", и с пониманием относятся к необходимости апдейтов.

У меня обратное впечатление. "Необходимость апдейтов" принимают только некоторые, уже опытные, и только если их чем-то соблазнили. Большинство или просто апдейтят не замечая (как рекомендуется в настройке Windows), или стоят на своём до последнего.

...

...

Я не вижу в этом ни одной серьёзной проблемы, VN>> Ты скажи, как именно ты собрался это реализовывать, и должны ли VN>> текущие реализации знать, что это уже не обычный IPv4 на 32 бита или VN>> нет, и как именно. Причём на всех уровнях. Например, как ты VN>> представляешь себе вместить 48 или 64 бита в struct sockaddr_in? Если кто-то работает с sockaddr_in по явным смещениям и ориентируется на его фиксированный размер вместо использования sizeof(sockaddr_in), тому придётся внести некоторые изменения в код. Примерно как тем, кто ориентировался на фиксированный тип time_t или int или long или size_t или off_t или прочих типов. Или на восьмибитность символа.

Увы, там несовместимостей значительно больше. Взять хотя бы возможность хранить v4-адрес одним long'ом, которая достаточно часто используется. Причём, будь это unsigned long, проблем было бы даже меньше, но оно таки у очень многих uint32_t. А если менять код - то уже нет фатальной разницы, на что именно менять. Но это ты пошёл в сторону вопроса о коде. Я же больше имел в виду проблемы собственно совместимости уже написанного. До определённой степени она есть - за счёт IPv4-mapped адресов. В принципе тебе ничто не мешает связаться с ::ffff:10.0.3.4 на ::ffff:192.168.1.5 так, чтобы соединение реально случилось по v4 (не помню, насколько стеки поддерживают автоматизацию этого действия, но даже сделать простой враппер с аллокацией v4 сокета вместо v6 будет тривиально). Насколько я вижу, всякие редхатофедоры это давно сделали: tcp 0 0 ::ffff:YY.193.194.194:80 ::ffff:XX.133.134.30:53671 TIME_WAIT - (чуть замаскировал первые октеты) Я не знаю, почему netstat в Fedora показывает часть соединений на один и тот же 80-й порт в чистом v4 синтаксисе, а часть - в v4-mapped v6, но такие строчки там есть и показывают, что соединение было принято объединённым v6/v4 сокетом.

Ничего - с utf-8 как-то смирились, так что смириться с изменением структуры sockaddr_in или in_addr тоже можно. По крайней мере, эти изменения существенно меньше, чем переписывание кода на IPv6 с совсем другими структурами и другим API.

Ну "смирились" про utf-8 - это жестокое преувеличение. Стало одним из возможных вариантов, более того, основным для большинства установок - это да, современный линукс на восьмибитке уже трудно себе представить. (Я вот никак не решусь на своей фряхе перейти на utf-8, хотя на сейчас всех препятствий осталось - перевести несколько файлов.) Но вначале переход был мучительным. Помнишь grep на RedHat 8.0, который в случае включения utf-8 локали начинал даже ascii текст разбирать в ~1000 раз медленнее? Потом это, конечно, залечили. Но опять-таки изменение структуры - это изменение на уровне программиста, то есть его хоть ясно, как решать. Есть более сложные и путаные вопросы, и в основном они в районе проблем межсетевого взаимодействия.

...

...

а при этом большинство проблем, которые возникают с IPv6, не возникли бы. VN>> Слабо верится. Любое расширение - это несовместимость. VN>> IPv6 имеет одну принципиально важную основу: оно исходит из подхода VN>> "помирать, так с музыкой" - простите, "если ломать, то так, чтобы VN>> хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет". Я считаю, что IPv6 имеет противоположную основу. Оно не ломает IPv4. А ломать придётся.

Ну формат заголовка пакета ведь уже сломали? Я что-то плохо верю в возможность автоматической конверсии заголовка даже в случае v4-mapped адресов на v6 части пути. Flow label потеряется. Часть v6 заголовков не может быть адекватно конвертирована в v4. И такого много. Значит, на этапе установления связи уже надо однозначно знать, каким вариантом будем связываться. На сейчас, если стек видит v4-mapped адрес, он таки переключается на v4, по крайней мере в Linux. На моём десктопе (OpenSuSE 11.3): === #!/usr/bin/env python import socket s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.bind(('::', 4444)) s.sendto('Hello v6 world\n', ('::ffff:192.168.1.104', 4444)) === Смотрим в tcpdump: 07:02:49.374514 IP 192.168.1.106.4444 > 192.168.1.104.4444: UDP, length 15 0x0000: 4500 002b 0000 4000 4011 a69f c0a8 016a E..+..@.@......j 0x0010: c0a8 0168 115c 115c 0017 a86e 4865 6c6c ...h.\.\...nHell 0x0020: 6f20 7636 2077 6f72 6c64 0a o.v6.world. По-твоему, этого недостаточно для совместимости? (Попробовал повторить на FreeBSD - отказалось на моменте конверсии getaddrinfo() текстового представления v6. Пока не знаю, это шутки питона или libc.) VN>> А что ты предложишь?

64-битных адресов хватит навсегда.

С этим я в принципе согласен, но при одном принципиальном условии: если отказаться от новомодных тенденций в автоконфигурации. На сейчас в v6, например, взаимодействие в пределах одного сетевого сегмента настраивается автоматически (я даже не уверен, можно ли тут сказать "настраивается") и работает гарантированно устойчиво (без конфликтов и с фиксированными адресами) независимо от момента настройки. Для v4 ты что сделаешь аналогом? Даже 169.254/16 это "подарок" Microsoft, а не органическое свойство протокола, и требует соответствующей поддержки в управлении сетевым стеком. И фиксированных адресов там нет, чуть включились в ином порядке в следующий раз - сели на другие адреса. Обычно они берутся просто случайным образом. Я бы, конечно, перерабатывал MAC и делал фиксированную последовательность для пробы, но сложилось уже иначе. И если ты думаешь, что для 64 бит можно это повторить, выделив старшие 16 бит фиксированно (или чуть меньше, чтобы разные локальные сети делать), а младшие 48 брать из MAC'а, то я тебе вынужден буду возразить, что не MAC единым живо человечество. Вот, например, у Infiniband аналог MAC карточки (зовётся GUID) занимает уже 8 байт, а L2 адрес там 20 байт (старшие 4 по местной политике виртуализации сетевых интерфейсов, а 16 методом, идентичным формированию v6 link-local): # ip link show ib0 6: ib0: mtu 2044 qdisc pfifo_fast state UP qlen 256 link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:04:7a:85 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff и ты не сможешь преобразовать гарантированно бесконфликтно 64 бита GUID в 64 бита link-local адреса со стандартным для этого префиксом. Я не буду сейчас агитировать за эту автоконфигурацию, она мне самому весьма сомнительна. Если бы адрес уровня link-local или добавки к стандартному префиксу вычислялись на основании хэша MAC и имели хотя бы 24-32 бита переменной части, то конфликтов наверняка не было бы в ~99.9999% случаев. В этом смысле я тоже не вижу смысла держать полные 64 на локальную часть. (Тем более что реального обоснования им никогда и не было, см. мой постинг в ЖЖ - схема global+local сложилось как два параллельно и одновременно уникальных адреса в одном "адресе", и глобальный был тоже 64 бита; обоснования перехода на 128 не было; так что тут просто результат надругательства над здравым смыслом). Но далее оно обросло большим и толстым слоем надстроек и наслоений. Хороший пример из них - "mobile address" в той же системе адресации. Это, кстати, ещё раз на тему автоконфигурации: если каждому телефону дадут по MAC'у, управление сетями резко упрощается.

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

На сейчас это уже малосущественная разница. Ты можешь держать адрес и как 128-битное целое, а если тебе этого не позволяет напрямую язык (многие позволяют) - делаешь адекватную библиотеку. На C++ создание типа данных [u]int128_t на основании имеющихся целых - задача для школьника. На C чуть сложнее (будет путаное API), но не сложнее, чем работать со всякими div_t или sockaddr_in. Ты наверняка читал мои наезды на IPv6. Заметь, я там ни слова не говорил про сложность хранения/передачи/etc. адресов - потому что jIMHO её нет. Проблема в первую очередь в работе человека с этими адресами. Никакой DNS не поможет нокеру, если сеть в дауне, резолвинг сломан, а надо по traceroute определить, через кого пошёл поток. И вообще админам всех типов работа резко усложняется - помнить кучу страшных цифр. И ещё в моих наездах претензией (второй основной) было то, что ради перехода на v6 не подогнали апдейт остальной сетевой организации. Начиная с самой структуры адреса (вообще ведь никто толком не думал, правильно ли это объединять идентификацию и раутинговые указания в одну сущность). Далее, - номер порта 16 бит - для бытового потребителя много, но для серьёзной системы - крайне мало. - TCP sequence numbers в 32 бита - сейчас просто несекьюрно, для современного мира надо 64 или 128 (вот тут уже можно не экономить) - формат DNS вообще надо переписать с нуля - проблемы MTU не решили, только усугубили. единственное что может чем-то помочь - требование минимума в 1280 байт (если кто не помнит, для v4 минимум - 68 (прописью: шестьдесят восемь байт)) всё это можно было решить за прошедшие 17 лет не раз, но никто не чешется, pardon my french. С этой точки зрения, до последних лет IPv6 - просто отвлекалово от реальных проблем.

Зачем нужен этот массив (и маршрутизация по flow label) - непонятно. Насколько с ним тяжело работать на больших скоростях - понятно.

В случае магистрального ISP типа твоей работы достаточно маршрутизации до /32, что принципиально не меняется по сравнению с v4 (всё равно смотрели полные 4 байта). Политика IANA+RIRs для v6 - выдавать только целые блоки /32 на AS - помогает оптимизировать основной случай (а не бардак всех размеров, как v4) вплоть до аппаратной поддержки. (И даже обсуждаемые /48 на PI это всего лишь ещё один фиксированный размер, а не шатание всех уровней от /26 до /19.) В более мелкие размеры и тем более на flow labels надо смотреть уже на уровне внутри ISP к своим клиентам, где скорости на порядки ниже, а техника разнообразнее. А там даже простой IDS сожрёт значительно больше ресурсов, чем маршрутизация по flow label. Так что не всё так грустно, как ты описываешь.

...

...

В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга, VN>> Не отдельными? А какая цена замены 32->64? Не более, чем, например, замена классического форвардинга на cef. И даже менее - там алгоритм другой, а тут просто изменяется кол-во битовых разрядов.

Так оно и при текущем v6 такое же, потому что младшие 64 начинают работать только в пределах последнего сегмента. Только твои 64 имеют неопределённую структуру, а в v6 она чётко определена для >99% практически значимых случаев (32 на AS, 16 на клиента, 16 на сеть клиента, 64 внутри той сети).

...

...

А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили. VN>> См. IPv4-compatible и IPv4-mapped адреса. IPv4 включается в IPv6 как VN>> частный случай. IPv4 мапится в IPv6, но тоже не совсем без проблем. Например, если у меня только v6 и собственный dns, а у гугля только v4, то при обращении к гуглю я получу "host not found" - чтобы этого не было, я должен использовать специальный dns 6to4-гейта. А этот гейт мне ещё нужно где-то найти. Если я пользователь - понятно, спрашивать провайдера, а если я сам ISP, имеющий только v6-адреса, что делать?

DNS тут почти ни при чём. Давай не будем сейчас вспоминать конкретную битность, названия протоколов и т.д., просто назовём - формат A (более узкий) и формат B (более широкий). Если у клиента адрес типа B, то сервер с типом только A не сможет с ним работать без дополнительного шлюза (фактически NAT). Если у сервера адрес типа B, проблема та же. Кроме того, ты вспоминаешь DNS - опять-таки, это метод узнать адрес, и если клиент не может понимать адреса типа B, ему без разницы, есть ли к нему шлюз. Из этого следует, что на переходный период нужно делать, чтобы и у клиентов и у серверов было оба варианта адреса, ну и, само собой, их поддержка. По твоему конкретному примеру. Во-первых, не host not found, а no data (а если мы говорим про DNS, будет не NXDOMAIN, а положительный ответ, но с нулевым answer count). Во-вторых... да, если провайдер - сам организуй этот гейт:) но дело в нём, а не в DNS, который будет уже вспомогательным средством. И на переходный период таки не надо делать v6 only, надо давать всегда два адреса.

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

А это будет постепенным процессом. Сначала начнут раздавать v6 адреса по желанию. Потом начнутся v6-only ресурсы. Так что плющить и метелить будет долго, но очень медленно и постепенно...

И даже смешнее. Если всё-таки IPv6 начнёт вытеснять IPv4, то IPv4-адреса начнут освобождаться, дефицит исчезнет, а без дефицита IPv4 вновь получит преимущества перед IPv6. Классическая система лисы и зайцы, находящаяся в динамическом равновесии. Лисы никогда не смогут съесть всех зайцев.

А вот против этого уже сыграет привычка. Если все сидят на v6, то v4 уже не будет удобным. Это надо подымать вторую систему адресации... а зачем? VN>> Но протокол всё равно надо менять, ты в рамках того VN>> же не сможешь включить более 32 бит не меняя формат пакета.

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

Увы, мешает. Если бы он изначально расширялся, было бы проще. (Так сделано в стеке ISO, причём достаточно дешёвыми методами.) -netch-

Hi! (из накопившегося)

другое дело что сети массового абонентского ШПД гораздо проще и правильнее перевести на 6 версию и стыковать с 4 сетью через NAT тем самым все вопросы-то и решаются лет на 50 вперед

По-моему это называется не NAT, а 6to4 (4to6?) и влечет за собой все те же, обучные для NAT сложности, начиная с вопроса о том, сколько IPv4 адресов расходовать на абонента и где эти адреса взять.

Чем тебе не угодил NAT для миллионов домашних хомячков?

У NAT для домашнего ШПД много недостатков: 1. При классическом NAT (1 public IP = 1 private IP) все равно нужно много puclic IP, а их мало. 2. При PAT (на один public IP вешаем до 64K клиентов), все эти клиенты начинают звонить в support и спрашивать "а почему на rapidshare написано, что с моего IP уже качают"? 3. NAT-box'ы не тянут. 4. Мой компьютер дома уже и так за NAT. И NAT за NAT работает плохо. Мало того, если ты мне выдал адрес 10.0.0.10 в кач-ве внешнего на мой домашний роутер, а я себе тот же адрес прописал в кач-ве внутреннего для "холодильника и микроволновки" (ну совпало так) - работает еще хуже. (Хотя может работать.)

Нафига делать NAT с v6 внутри и v4 снаружи? Тогда проще сделать 10/8 внутри, если наружу всё равно торчит NAT

Наружу в такой схеме торчит еще и v6 и в перспективе этот v6 может начать использоваться (чаще). Т.е. как бы это более переспективное решение...

И это всё из-за того, что IPv6 разрабатывали в 1992-1995, ... На мой взгляд, правильнее было бы расширить адресное пространство,

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

всё это можно было решить за прошедшие 17 лет не раз, но никто не чешется, pardon my french. С этой точки зрения, до последних лет

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

...

Ты представляешь в обозримом будущем v6-only ресурс? Ну вообще-то такие уже существуют.

http://onlyv6.com :)

Разумеется, это не гугл и не новостной сайт.

Я слышал про бесплатные v6-only сервисы для популяризации IPv6 :) В частности, про бесплатные v6-only news-servers... вот список, кстати: http://forums.sabnzbd.org/index.php?topic=51.msg120#msg120

И даже смешнее. Если всё-таки IPv6 начнёт вытеснять IPv4, то IPv4-адреса начнут освобождаться, дефицит исчезнет, а без дефицита IPv4 вновь получит преимущества перед IPv6. Классическая система

Думаю, этого не может не произойти, соотв-но мои соображения про рынок IPv4.

У гугла вообще нет v6 адреса... Пока явно не попросишь для своих резолверов открыть v6 и не пообещаешь что: - понимаешь все риски - будешь помогать дигностировать проблемы доступности v6 - для массового клиента не доедет AAAA

Последний пункт неправильный. Goolge просит самих помогать своим клиентам, а не "открыть провадеру IPv6, только клиентам не давать".

если каждому телефону дадут по MAC'у, управление сетями резко упрощается.

У телефонов полно MAC-адресов. У моего их по-моему 3 или 4.

обсуждаемые /48 на PI

Их уже довольно давно выдают: wget -qO - ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest | grep ipv6 | grep -c '|48|' 402

Большие - уже могли себя сами удовлетворить на годы вперед, да и слияния-поглощения-реорганизации для них во многом решат проблему. Согласитесь, когда у тебя /16 - ими проще распоряжаться, чем когда

Соглашусь, что проще, когда у тебя /8. Но я знаю всего один ISP, у к-рого есть /8. Зато я знаю очень много ISP, у к-рых гораздо больше, чем 65K клиентов (/16) им нужно регулярно получать новые миллионы адресов. Для примера, поищи данные о количестве продающихся iPhone'ов. Они обычно все в online и не за NAT. В общем, я не верю в запасы на годы вперед у больших провадеров. Скорее наоборот, они пострадают первыми. -- Mike

Hi Pavel,

Там, кстати, есть ещё одни грабли, на которые мы уже наступили: неоднозначность записи IPv6-адреса. Это как возможность сокращать нули в виде "::" в произвольном месте, так и возможность записать адрес в верхнем или в нижнем регистре. В результате - текстовое сравнение адреса не работает. А это всякие grep, "| match", "| include"... В конфиге адрес прописан одним способом, в выводе bgp-sum он показывается иначе, скрипт не срабатывает (не видит соответствия).

Тут, кстати "этот кто-то" уже не поленился и написал RFC, http://tools.ietf.org/html/rfc5952#section-4.2 осталось дождаться применения.

В ipv4 такое если есть, то в пренебрежимо малом масштабе (типа "ping 127.1").

И типа "193.193/16" :)

Фактически, оно примерно так в IPv6 и получается: старшие 32 бита адреса однозначно ставятся в соответствие номеру AS, блока /32 для автономки должно хватить

/32 содержит 65K /48х; /16 в IPv4 содержит столько же адресов. Некоторым не хватает :) -- Mike Луц по частям не продаётся

Hi Pavel,

Btw, а почему ты считаешь адреса /48? На хост разве не /64 выделяется?

Потому что кто-то когда-то так написал в RFC и сейчас самая распространенная практика - один /48 на клиента (любого размера). Один /48 = 65K подсетей. Еще кто-то решил, что это многовато, потому есть нек-рая тенденция давать на клиента не /48, а /56 (256 подсетей). По-моему эта тенденция еще не доминирует. Давать /64 на клиента тоже можно, но этим ты лишаешь клиента иметь подсети. А в IPv4 клиенты имеют дома подсети, за счет NAT, к-рого в IPv6 как бы нет. -- Mike

Hi Andrey,

Интересно, насколько легко/тяжело RIPE сейчас выдает IPv6 PI в дополнение к уже имеющимся IPv4 ? Им все так же нужен основательный justification ?

См. http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider Там нет никаких требований, кроме multihomed, но, к сожалению, по policy IPv6 PI нельзя использовать для раздачи адресов пользователям. Т.е. считается, что провайдеры должны получать allocation. -- Mike

On Mon, Feb 07, 2011 at 11:18:02AM -0800, Volodymyr Yakovenko wrote:

2011/2/7 Alexandre Snarskii :

...

On Mon, Feb 07, 2011 at 09:22:53AM -0800, Volodymyr Yakovenko wrote:

...

Панове!

 Так радоваться надо, и на нашу улицу пришел праздник,  чем плотнее безголовые СМИ нагнетут глупой шумихи,  тем больше будет работы вскякой и разной для сетевых  инженеров :-) А ля проблема 2000 года в сетевой профиль :-)

Мьсе не понимает :( Сетевые инженеры на backbone'ах ipv6 уже давным-давно подняли.

Ммм ... Саша, у вендора на букву J все еще много проблем с работой IPv6 in general и в части транспорта оного поверх MPLS TE backbone in particular. Через сколько кварталов после выхода MX3D железа J выпустил JunOS, который официально поддерживал v6 forwarding?

Если у тебя такие суровые требования к v6 forwarding - please, use DPC, на них как-то я проблем не видел. И с другой стороны - да, ipv6 forwarding в первых версиях софта под новое железо мог быть глючным (ибо marketing pressure по работоспособности этой фичи таки поменьше будет), но по крайней мере рано или поздно и это тоже до ума доведут.

Это я все к тому, что поддержка v6 со стороны вендоров все еще баловство и багодром, в какомто виде это все запускают, но реальных объемов траффика там пока нет. Вот как он появится - все станет сильно веселее :-)

Существующие обьемы траффика идут ровно через тот же самый hardware-based forwarding plane[1], так что никакой зависимости от увеличения обьемов я как-то не вижу. [1]: ну да, на нормальных раутерах. А не как у некоторых, у которых ipv6 uRPF вводит ipv6 траффик в process-switching. -- In theory, there is no difference between theory and practice. But, in practice, there is.

Wed, Feb 09, 2011 at 13:34:53, mp wrote about "Re: [uanog] Изя всё.":

Давать /64 на клиента тоже можно, но этим ты лишаешь клиента иметь подсети.

Уточняй - подсети с автоконфигурацией. Потому что можно выдать ему хоть /126, весь софт это позволяет, но все адреса придётся назначать вручную или через знающий такие тонкости DHCP. [root@mon-2 ~]# ip a add fd44:dafa::2/112 dev ctl [root@mon-2 ~]# ip a show ctl 2: ctl: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:02:c9:f4:74:0e brd ff:ff:ff:ff:ff:ff inet 10.0.0.6/24 brd 10.0.0.255 scope global ctl inet6 fd44:dafa::2/112 scope global valid_lft forever preferred_lft forever inet6 fe80::202:c9ff:fef4:740e/64 scope link valid_lft forever preferred_lft forever [root@mon-2 ~]# ping6 -c 2 -w 3 fd44:dafa::1 PING fd44:dafa::1(fd44:dafa::1) 56 data bytes 64 bytes from fd44:dafa::1: icmp_seq=1 ttl=64 time=3.24 ms 64 bytes from fd44:dafa::1: icmp_seq=2 ttl=64 time=0.423 ms --- fd44:dafa::1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1005ms rtt min/avg/max/mdev = 0.423/1.834/3.246/1.412 ms (на соседнем тазу, понятно, сидел этот самый ::1)

А в IPv4 клиенты имеют дома подсети, за счет NAT, к-рого в IPv6 как бы нет.

А вот это следующий тонкий вопрос. В IPv6 NAT есть, несмотря на то, что формально никем не признаётся:) Кто-то хочет скрыть структуру сети, но есть и другие причины. Рассмотрим, например, "Волю", которая обычным кабельным клиентам статические адреса не даёт - и даже при услуге "фиксированный адрес" этот адрес может меняться, если клиент оказывается под другой головной станцией или ещё что-то поменялось в сети. Вопрос: что она и как даст клиентам? Нужно ли им будет перенумеровываться каждый раз, как будет выдан другой блок? А может, вместо /64 выдадут один адрес, сформированный из MAC модема и старших 64 бит сети под конкретной головной станцией? Тогда всё равно нужен будет NAT ради чего-то осмысленного. -netch-

Wed, Feb 09, 2011 at 12:35:52, mp wrote about "Re: [uanog] Изя всё.":

...

В ipv4 такое если есть, то в пренебрежимо малом масштабе (типа "ping 127.1"). И типа "193.193/16" :)

Это уже контекст сети, никак не стандартный случай.

...

Фактически, оно примерно так в IPv6 и получается: старшие 32 бита адреса однозначно ставятся в соответствие номеру AS, блока /32 для автономки должно хватить

/32 содержит 65K /48х; /16 в IPv4 содержит столько же адресов. Некоторым не хватает :)

А зачем ты сравниваешь один IP в случае v4 и целую клиентскую сеть в случае v6? Если уж сравнивать, то нормально сравнимые выдачи. -netch-

Wed, Feb 09, 2011 at 13:26:32, gul wrote about "Re: [uanog] Изя всё.":

Тут я имел ввиду более не код, а выполнение. Делать производительные роутеры 64-битными - это нормально. А 128-битными (чтобы IP-адрес был одним словом и помещался в один регистр) - уже черезчур. А значит, роутерам (как PC, так и железным) придётся работать с IPv6-адресами как с массивом, это дольше.

Мелкие раутеры не имеют обычно большой нагрузки, а крупные работают только со старшими 64 битами, если не 32.

Программистам в любом случае правильнее работать с struct in_addr, а как оно там внутри устроено (как длинное целое или как массив), ему не должно быть интересно.

Угу, только раньше было дико удобно делать что-то вроде printf("%08x\n", ntohl(sia.sin_addr.s_addr)) а так придётся полагаться на тяжёлые функции конверсии к "каноническому виду". VN>> И ещё в моих наездах претензией (второй основной) было то, что ради VN>> перехода на v6 не подогнали апдейт остальной сетевой организации.

Совершенно согласен. Если уж делать новую версию с нуля, надо было много чего поправить - ведь есть что. А вместо этого сделали что-то странное (обязательный ipsec, flow labels, размер пакетов до 4G - кому всё это надо?).

IPSec не обязателен. Не хочешь - не делай. Про пакеты до 4G я что-то не понял. Согласно RFC2460, payload length - 16 бит. Максимальный размер пакета - 65575 байт (40 на заголовок и 65535 на payload). Да, на 40 больше, чем в v4, ну и только. Flow labels - да, единственное что из этого списка реально смущает. VN>> Начиная с самой структуры адреса (вообще ведь никто толком не думал, VN>> правильно ли это объединять идентификацию и раутинговые указания в VN>> одну сущность).

Тут не понял. Вроде ж, разные сущности, и соответствие между одним и другим задаёт таблица роутинга.

Ты в таблице делаешь лукап именно адреса.

Фактически, оно примерно так в IPv6 и получается: старшие 32 бита адреса однозначно ставятся в соответствие номеру AS, блока /32 для автономки должно хватить, и fullview не растёт (в смысле, растёт лишь с кол-вом автономных систем).

И роста количества AS достаточно, чтобы испортить всю малину. Впрочем, так делать не будут. Крупный оператор на 200K юзеров будет вынужден, давая каждому /48, заводить уже 4 таких /32.

Не понимаю, откуда могут появиться v6-only ресурсы, пока есть хотя бы 10% v4-only пользователей. Ресурс ведь не захочет их лишаться.

А если новый ресурс и ему v4 адреса просто не досталось? (И тут про телефоны говорили - да, хороший пример, как вендоры могут выкрутить) -netch-

Wed, Feb 09, 2011 at 20:50:16, snar wrote about "Re: [uanog] Изя всё.":

...

...

Фактически, оно примерно так в IPv6 и получается: старшие 32 бита адреса однозначно ставятся в соответствие номеру AS, блока /32 для автономки должно хватить, и fullview не растёт (в смысле, растёт лишь с кол-вом автономных систем). И роста количества AS достаточно, чтобы испортить всю малину. Впрочем, так делать не будут. Крупный оператор на 200K юзеров будет вынужден, давая каждому /48, заводить уже 4 таких /32. Вообще говоря, RIPE, выдавая /32, сразу резервирует /29 (512k по /48), чтобы когда тебе потребуется следующий /32 твой allocation просто расширят с /32 до /31 и так далее. У остальных RIR, iirc, тот же принцип.

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

...

...

Не понимаю, откуда могут появиться v6-only ресурсы, пока есть хотя бы 10% v4-only пользователей. Ресурс ведь не захочет их лишаться. А если новый ресурс и ему v4 адреса просто не досталось? Пойдет на такой хостинг, где ему предоставят этот ipv4 за $$$$. Возможно, выдавив оттуда ресурс, который готов платить только $$$, но это же все равно был плохой, негодный, никому не интересный ресурс, nes pa? :)

Значит, другому ресурсу в результате не достанется адреса. Quod Erat Demonstrandum, или, другими словами, не всё то золото, что под ногами. -netch-

Wed, Feb 09, 2011 at 20:36:25, snar wrote about "Re: [uanog] Изя всё.":

Вообще клиенту для того и предполагается выдавать /56-/48, чтобы он получив свою сеть мог автоматом (autoconfiguration'ом) переконфигурить все свои subnet'ы даже в случае динамической выдачи сети.

И никакого NAT'а не нужно. И никакого хитрого DHCP.

Ну да, только на самом деле "хитрый DHCP" искусно спрятан в реализации ND (RFC2461). А ты защищаешь подход, который сложился в виде 1. <strike>Любой программе достаточно 640K</strike> Все локальные сети должны быть /64, поэтому все наши умные автоконфигурации не будут знать другого случая 2. Автоконфигурация умеет только /64, поэтому мы будем затачиваться под неё несмотря на все запросы другого подхода и в итоге это просто порочный круг от лени и гордыни.

Холодильнику, ему, как бы, пофиг, какой именно ipv6 префикс ему анонсировал раутер, ему важно чтобы он после этого смог со своего адреса в этой сети сходить в магазин, пива хозяину заказать... :)

А он и так сходит, проблема-то. Разница между автоконфигурацией с /64 и автоконфигурацией с более коротким prefixlen в том, что в случае /64 в сферической в вакууме идеальной обстановке не надо никак проверять, можешь ты взять такой адрес или нет - просто получил от раутера базу сети, добавил EUI64 из своего MAC и пошёл плясать. А в прочих, согласно той же теории в вакууме, надо ещё послушать, не отозвался ли кто на этот адрес, если отозвался - сгенерировать другой и снова проверить... и таки да, иногда при этом адреса могут выдаваться иначе. А в случае /64 они фиксированы (если префикс не меняется). Всё, казалось бы, понятно. А теперь слушаем другую сторону: 1. Всё это выливается в небольшую добавку кода. Она пишется 1 раз на стек, а если учесть, что >99% embedded в ближайшее время будет только Linux, то один раз на эти 99%. Ну и Windows для изиотов (не описка), один раз на 90% от оставшегося. 2. Преимущества от постоянного адреса, безконфликтного гарантированно (в тех пределах, в которых китайцы не забыли прошить MAC'и), а не в 99.99999% случаев, нужны дай бог чтоб 1% потребителей, которые ради такого случая могут и купить блочок побольше. 3. Даже с такой уникализацией можно было не гнаться за EUI64 и обойтись MAC'ами (48 бит вместо 64). 4. На самом деле такие фиксированные в конце и автоматические в начале адреса нахер никому не нужны. Серверам и прочим сущностям, которым адрес важнее автоподъёма, обычно дают prefix::1, prefix::2 и так далее, чтобы легко помнить и чтобы мелкая фигня типа смены MAC не приводила к переписыванию всего подряд (и не надо надеяться на DNS), и уж тем более для них не будут залагаться на внешний блок - им дадут вместо этого site-local адреса (по ULA или аналогу). Клиентским станциям, которые во всяких ACL'ях - тоже.

PS: а такого провайдера который при услуге фиксированного адреса этот фиксированный адрес регулярно меняет (причем, скорее всего, без заблаговременного уведомления) стоит послать в одно место.

И это говорит тот, кто сам перенумеровывал клиентов при перестройке сети? Про "регулярно" это твоя додумка, я никакой причины такого вывода не давал. -netch-

On Wed, Feb 09, 2011 at 03:00:00PM +0100, Mike Petrusha wrote:

Hi Andrey,

...

Интересно, насколько легко/тяжело RIPE сейчас выдает IPv6 PI в дополнение к уже имеющимся IPv4 ? Им все так же нужен основательный justification ?

См. http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider

Там нет никаких требований, кроме multihomed, но, к сожалению, по policy IPv6 PI нельзя использовать для раздачи адресов пользователям.

Т.е. считается, что провайдеры должны получать allocation.

... и платить RIPE ~ 2 тыс. EUR в год за членство и статус LIR. Такое вот ненавязчивое принуждение. -- Kind Regards, Alexander Shikoff AMS1-UANIC

On Thu, Feb 10, 2011 at 09:34:54AM +0200, Valentin Nechayev wrote:

Thu, Feb 10, 2011 at 09:07:10, minotaur wrote about "Re: [uanog] Изя всё.":

...

...

PI нельзя использовать для раздачи адресов пользователям.

Т.е. считается, что провайдеры должны получать allocation.

... и платить RIPE ~ 2 тыс. EUR в год за членство и статус LIR. Такое вот ненавязчивое принуждение.

Ну вообще-то можно держать один LIR на нескольких. Лишь бы потом не подрались за коммерческие интересы. А так - у меня сейчас возникает сильное сомнение в смысле держать организацию такого масштаба и такого смысла в местах типа Голландии. Фактически 2/3 этих денег уходит на поддержку MJ, велосипедистов, индусов и прочего стрёма, вместо развития IT.

Ну почему же? :) Новый сайт анонсировали ж ;) А что такое MJ? Я не в теме... -- Kind Regards, Alexander Shikoff AMS1-UANIC

Hi Alexander,

...

...

Интересно, насколько легко/тяжело RIPE сейчас выдает IPv6 PI в дополнение к уже имеющимся IPv4 ? Там нет никаких требований, кроме multihomed, но, к сожалению, по policy IPv6 PI нельзя использовать для раздачи адресов пользователям. Т.е. считается, что провайдеры должны получать allocation. ... и платить RIPE ~ 2 тыс. EUR в год за членство и статус LIR. Такое вот ненавязчивое принуждение.

Такой вот ненавязчивый результат того, что предложившего IPv6 PI policy этот аспект не интересовал, а недовольные неспособны даже написать "я возражаю" в нужную рассылку. Не говоря уж о том, чтобы самому аж заполнить табличку из 5-и клеток и предложить policy, по к-рому это можно будет выдавать. Думаю, еще более яркое возмущение будет, когда у RIPE NCC останется последняя /8, из к-рой не будут выдавать PI, а только allocations и только по /22 http://tinyurl.com/ripelast8 (По аналогичной причине.) -- Mike

Hi Alexandre,

...

Впрочем, так делать не будут. Крупный оператор на 200K юзеров будет вынужден, давая каждому /48, заводить уже 4 таких /32.

Вообще говоря, RIPE, выдавая /32, сразу резервирует /29 (512k по /48),

Это на будущее. Выдается немало блоков размера больше чем /32. По-моему даже /19 есть.

...

/32 содержит 65K /48х; /16 в IPv4 содержит столько же адресов. А зачем ты сравниваешь один IP в случае v4 и целую клиентскую сеть в случае v6?

Потому что мне кажется, что ШПД и мобилки доминируют и для них картина именно такая - они получают один IP в случае v4 и целую клиентскую сеть в случае v6. -- Mike Who me? I just wander from room to room.

Thu, Feb 10, 2011 at 09:31:56, mp wrote about "Re: [uanog] Изя всё.":

...

...

... и платить RIPE ~ 2 тыс. EUR в год за членство и статус LIR. Такое вот ненавязчивое принуждение. Ну вообще-то можно держать один LIR на нескольких. Лишь бы потом не подрались за коммерческие интересы. Вот это наш метод. Когда два дяди обсуждают policy, мы принципиально не будем мешать, а потом поищем workaround.

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

...

А так - у меня сейчас возникает сильное сомнение в смысле держать организацию такого масштаба и такого смысла в местах типа Голландии. Фактически 2/3 этих денег уходит на поддержку MJ, велосипедистов, индусов и прочего стрёма, вместо развития IT.

Я думаю (глядя на цифру), данное мнение - результат традиционного представления "в Голландии все наркоманы", а не результат чтения фин. отчета RIPE NCC.

Ты про личные налоги расскажи, на что уходят государственные деньги, из чего и как складывается стоимость недвижимости, оборудования и материалов, выполняемых работ и тэ дэ. И увидишь, что по сумме скрытых налогов и поборов цифра будет не менее 70%, а местами и 90%. А по плоскому отчёту без раскрытия, что за ним стоит - ну да, конечно, всё будет салом в шоколаде.

Ну и пункт про "развитие IT" очень удивляет.

Чем?

Опять же - главное ни в коем случае не участвовать в обсуждении бюджета RIPE NCC на след. год. А то потом как-то возмущаться неудобно.

Как ты можешь заметить по внимательному чтению, я не говорю про бюджет одного отдельно взятого RIPE. Он мне неактуален. -netch-

Hi Valentin,

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

Тебя забанили в тех списках рассылки при рождении?

(Это я уж не вспоминаю, что все "обсуждения полиси" - это как европейская демократия - старательно нарисованная возможность свободного выбора.)

Т.е. ты-то знаешь, что в тех списках рассылки на самом деле есть секретный модератор? Кстати, а случай с Московским RIR'ом твои аргументы не опровергает?

Ты про личные налоги расскажи, на что уходят государственные деньги, из чего и как складывается стоимость недвижимости, оборудования и материалов, выполняемых работ и тэ дэ. И увидишь, что по сумме скрытых налогов и поборов цифра будет не менее 70%, а местами и 90%.

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

А по плоскому отчёту без раскрытия, что за ним стоит - ну да, конечно, всё будет салом в шоколаде.

А есть плоский отчет без раскрытия? Коноплю скрыли?

...

Ну и пункт про "развитие IT" очень удивляет. Чем?

Противоречивостью.

Как ты можешь заметить по внимательному чтению, я не говорю про бюджет одного отдельно взятого RIPE. Он мне неактуален.

А, тогда другое дело. Ты имел в виду какую-то другую организацию, к-рую нужно не держать в Голландии, т.к. она тратит много денег на коноплю. Думаю, ты имел в виду Гаагский Трибунал. -- Mike Чтоб ты свопился на одну дискету...

Thu, Feb 10, 2011 at 09:58:45, mp wrote about "Re: [uanog] Изя всё.":

...

Наезд не в кассу. Я никогда не был тем, кто имеет право и возможность обсуждать полиси. Тебя забанили в тех списках рассылки при рождении?

Я никогда не представлял никакой LIR.

...

(Это я уж не вспоминаю, что все "обсуждения полиси" - это как европейская демократия - старательно нарисованная возможность свободного выбора.) Т.е. ты-то знаешь, что в тех списках рассылки на самом деле есть секретный модератор?

Нет, именно такой сущности там нет.

...

Ты про личные налоги расскажи, на что уходят государственные деньги, из чего и как складывается стоимость недвижимости, оборудования и материалов, выполняемых работ и тэ дэ. И увидишь, что по сумме скрытых налогов и поборов цифра будет не менее 70%, а местами и 90%. Ну, давай и ты про это все расскажи. Википедии перецитируемся. И, конечно, из того, что скрытых налогов 70% следует, что все деньги голландцы тратят на коноплю. Не поспоришь.

Я такого не говорил, не передёргивай.

А, тогда другое дело. Ты имел в виду какую-то другую организацию, к-рую нужно не держать в Голландии, т.к. она тратит много денег на коноплю. Думаю, ты имел в виду Гаагский Трибунал.

Ладно, хочешь огрызаться вместо чтения - я не могу возражать этому.;) -netch-

On Thu, Feb 10, 2011 at 09:46:59AM +0100, Mike Petrusha wrote:

...

...

Так а они таки есть, реально работающие v6-v4 nat? Вот можно прямо сейчас взять какую-нибудь программулину и поставить на какой-то сервер и натить клиентов?

Теоретически - есть.

Практически - они на порядок сложнее существующих NAT44 решений: представь, твой ipv6-only клиент коннектится к ipv6-адресу 2001:1b00:e:bb::302. Как ты из этого факта узнаешь, что у этого хоста есть и ipv4-адрес ?

А зачем нужно это узнать и этому помешать?

Согласен, пример не совсем корректный. -- In theory, there is no difference between theory and practice. But, in practice, there is.

Just FYI, поднимай mtu на ib, это отлично работает [root@zzz02 ~]# ip li | grep ib0 5: ib0: mtu 65520 qdisc pfifo_fast qlen 256 [root@zzz02 ~]# lspci | grep Infi 08:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) CONNECTED_MODE=yes само-собой

На практике таких линков не встречается. Из реально видимых сетей локального подключения остался Ethernet, у которого 9000 даже в не всеми поддерживаемом jumbo frames, и всё. Из тех, с которыми сейчас работаю, Infiniband - у него обычно цифры вроде 2044. Я думаю, реально существующие стеки при попытке описать линк с MTU>65535 начнут глючить не по-детски.

...

...

...

Не понимаю, откуда могут появиться v6-only ресурсы, пока есть хотя бы 10% v4-only пользователей. Ресурс ведь не захочет их лишаться.  VN>> А если новый ресурс и ему v4 адреса просто не досталось? Будет искать, где купить. Представь себя на месте админа или владельца такого ресурса - как бы ты поступил?

Представляю. А если он цену не потянет? Вполне возможно, уже к 2020 к разнообразным бесплатным или дешёвым хостингам будет только v6 доступ. А те, кто толще, будут покупать 1-2 v4 (для несчастных) и держать пулы v6 для остальных.

-netch-

-- Yours, Max

On Thu, Feb 10, 2011 at 08:25:06AM +0200, Valentin Nechayev wrote:

...

Вообще клиенту для того и предполагается выдавать /56-/48, чтобы он получив свою сеть мог автоматом (autoconfiguration'ом) переконфигурить все свои subnet'ы даже в случае динамической выдачи сети.

И никакого NAT'а не нужно. И никакого хитрого DHCP.

Ну да, только на самом деле "хитрый DHCP" искусно спрятан в реализации ND (RFC2461). А ты защищаешь подход, который сложился в виде

Нетч, я этот подход не защищаю. Я даже признаЮ, что он более кривой, чем DHCP, и что, возможно, когда-нибудь он будет признан deprecated в пользу DHCPv6. Но до тех пор, пока останется legacy оборудование рассчитанное на этот и только на этот подход - на один сегмент с разношерстным оборудованием проще выдавать /64. Да, в некоторых случаях (межраутерные point-to-point линки, которые конфигурятся по любому вручную) это правило можно и нарушить (и в реальности я туда выдаю /124), и это вполне себе работает. "До тех пор, пока на разработчиков сетевого железа не снизойдет, и они не вспомнят, что согласно RFC старшие 128 адресов любого subnet'а зарезервированы под anycast". (с) Iljitsch van Beijnum, в вольном переводе.

...

PS: а такого провайдера который при услуге фиксированного адреса этот фиксированный адрес регулярно меняет (причем, скорее всего, без заблаговременного уведомления) стоит послать в одно место.

И это говорит тот, кто сам перенумеровывал клиентов при перестройке сети? Про "регулярно" это твоя додумка, я никакой причины такого вывода не давал.

Отвечалось вот на эту фразу: ----------------------- quote starts --------------------------- Рассмотрим, например, "Волю", которая обычным кабельным клиентам статические адреса не даёт - и даже при услуге "фиксированный адрес" этот адрес может меняться, если клиент оказывается под другой головной станцией или ещё что-то поменялось в сети. ------------------------ quote ends ---------------------------- Плановые изменения адресов при реконфигурации сети, с заблаговременным предупреждением клиентов, с плавным переходом с одной конфигурации на другую, это, согласись, несколько не "или ещё что-то поменялось в сети". -- In theory, there is no difference between theory and practice. But, in practice, there is.

Из центосовского if-ib if [ "${CONNECTED_MODE}" = yes ]; then echo connected > /sys/class/net/${DEVICE}/mode # cap the MTU where we should based upon mode if [ -n "${MTU}" -a $MTU -gt 65520 ]; then MTU=65520 fi else echo datagram > /sys/class/net/${DEVICE}/mode # cap the MTU where we should based upon mode if [ -n "${MTU}" -a $MTU -gt 2044 ]; then MTU=2044 fi fi fi пока не переведешь, не будет большого mtu и qos будет включен. Больше нельзя, там какие-то ограничения самой HCA и архитектуры, я не вдавался в подробности. ессно qos вырубается, это сеттинг для single application 10 февраля 2011 г. 11:51 пользователь Valentin Nechayev написал:

 Thu, Feb 10, 2011 at 11:44:24, speransky wrote about "[uanog] Re: [uanog] Изя всё.":

...

[root@zzz02 ~]# ip li | grep ib0 5: ib0: mtu 65520 qdisc pfifo_fast qlen 256 [root@zzz02 ~]# lspci | grep Infi 08:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)

Что-то мешает.

# ip link set ib0 mtu 2044 # ip link set ib0 mtu 2045 RTNETLINK answers: Invalid argument

# lspci | grep Infi 06:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX IB QDR, PCIe 2.0 5GT/s] (rev a0) # uname -mrs Linux 2.6.27-tmc-srv-tmc115 x86_64

...

CONNECTED_MODE=yes само-собой

У меня такого слова нет в /etc.

Ну и я не уверен, что с таким MTU не начнётся торможение срочных пакетов.

А больше 64K у тебя строится?

-netch-

-- Yours, Max

Hi Valentin,

...

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

Хочу уточнить. Все желающие могут (имеют право) предлагать и обсуждать полиси, в любом RIRе, включая RIPE NCC. Это делается путем подписки на соотв-е списки рассылки. Полиси обычно принимаются путем "поиска консенсуса", а не голосованием. Таких желающих очень мало, что на мой взгляд сильно сказывается на качестве результата. Примерно такая же ситуация с разработкой интеренет-стандартов. "Возможность обсуждать" - слишком широкое понятие, но в целом участвовать в обсуждении обычно полиси легче, чем, скажем, в разработке FreeBSD. Потому что для разработки нужно уметь не только писать, а еще и программировать. Всем желающим участвовать в изменении полиси и страдающим от несовершенства работы Google Translate по возможности помогу с переводом. К примеру, еще не поздно предложить выдавать PI из последнего /8. -- Mike

According to Serge Negodyuck: Hi!

10 февраля 2011 г. 12:33 пользователь Andrey Blochintsev написал:

...

On Thu, Feb 10, 2011 at 12:24 +0200, Taras Heychenko wrote:

...

Я что-то не помню мобилок с поддержкой ipv6.

А андроиды не умеют?

Айфоны и андроиды ipv6 по wi-fi точно умеют. А вот как обстоит с ipv6 через 3g неизвестно. Никто не протестировал потому, что никто из операторов не умеет.

Не знаю, как андроиды, а iPhone умеют ipv6, кажется, только по wi-fi. -- Taras Heychenko

Hi Valentin,

Политика IANA+RIRs для v6 - выдавать только целые блоки /32 на AS - помогает оптимизировать основной случай (а не бардак всех размеров, как v4) вплоть до аппаратной поддержки. (И даже обсуждаемые /48 на PI это всего лишь ещё один фиксированный размер, а не шатание всех уровней от /26 до /19.)

И вот тут еще: в IPv6 уже выдаются блоки любых размеров, от /48 до /19 (а многие считают, что до /13, т.к. это размер куска, к-рый получил US Department of Defence.) Текущее IPv6 PI полиси в принципе подразумевает, что выданные /48 будут анонситься по одному, но врядли этого стоит ожидать. Скорее найдутся желающие поменять полиси и разрешить выдачу больших v6 PI блоков провайдерам. Так что увы. -- Mike А зомби здесь тихие.

Hi Valentin,

...

...

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

Это не требуется. В создании полиси участвуют все желающие, со всего мира. К примеру полиси по использованию последнего /8 http://www.ripe.net/ripe/policies/proposals/2010-02 предложил (насколько я знаю) товарищ из Австралии. P.S. А netstat на OSX обрезает IPv6 адреса в выводе, так что от обоих адресов видны только куски, за исключением счастливых случаев, когда серверам выдали ::1 и оно сжалось в 16 символов :( P.P.S. Кстати про Google и IPv6. На youtube IPv6 давно включен и, насколько я понимаю, там оно для всех работает. (Не на самом youtube.com, а на серверах, где flash content хранится.) -- Mike

2000/12=166 EUR в месяц - интерестно, а сотрудника тех.поддержки за такие деньги найти можно? ;) Maxim Tuliuk On 10 Feb 2011, at 08:07, Alexander Shikoff wrote:

On Wed, Feb 09, 2011 at 03:00:00PM +0100, Mike Petrusha wrote:

...

Hi Andrey,

...

Интересно, насколько легко/тяжело RIPE сейчас выдает IPv6 PI в дополнение к уже имеющимся IPv4 ? Им все так же нужен основательный justification ?

См. http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider

Там нет никаких требований, кроме multihomed, но, к сожалению, по policy IPv6 PI нельзя использовать для раздачи адресов пользователям.

Т.е. считается, что провайдеры должны получать allocation.

... и платить RIPE ~ 2 тыс. EUR в год за членство и статус LIR. Такое вот ненавязчивое принуждение.

-- Kind Regards, Alexander Shikoff AMS1-UANIC

On Thu, Feb 10, 2011 at 11:23:03PM +0100, Maxim Tuliuk wrote:

2000/12=166 EUR в месяц - интерестно, а сотрудника тех.поддержки за такие деньги найти можно? ;)

Запросто, не указаны ж "объём работ" и подобное. -- Best regards, Paul Arakelyan.