Max Tulyev wrote:

Hi!

С сегодняшнего дня началась выдача IPv6 PI адресов.

Пропал Калабухов -- With best regards, Gregory Edigarov

On Wed, May 06, 2009 at 03:01:28AM -0700, Volodymyr Yakovenko wrote:

2009/5/6 Gregory Edigarov :

...

Max Tulyev wrote:

...

Hi!

С сегодняшнего дня началась выдача IPv6 PI адресов.

Пропал Калабухов

Ху из Калабухов?

Вовик, ну тебе-то предлагать воспользоваться Гуглем - это вообще оксюморон какой-то :) PS: была на каком-то nanog'е хорошая презентация на предмет того, что ipv6 does not scale. И IPv6 PI - это хороший прыжок в сторону того, что оно действительно не будет scalable.

Добрый день! On Wed, May 06, 2009 at 03:12:53AM -0700, Volodymyr Yakovenko wrote:

...

...

...

...

С сегодняшнего дня началась выдача IPv6 PI адресов.

Пропал Калабухов

Ху из Калабухов?

Вовик, ну тебе-то предлагать воспользоваться Гуглем - это вообще оксюморон какой-то :)

:-)

...

PS: была на каком-то nanog'е хорошая презентация на предмет того, что ipv6 does not scale. И IPv6 PI - это хороший прыжок в сторону того, что оно действительно не будет scalable.

Угу, на RIPE-овке не далее как 10мин назад обсуждали что делать с proposal-ом о multiply /32 v6 allocations for same LIR. Пока ничего не решили, но чтото мне кажется, что policy будет relaxed и LIR-вые /32 можно будет легально де-агрегировать до /24.

Наверное имелось ввиду "...до /48". И будет тоже самое что с IPv4... :( Радует только то, что IPv6 PI можно легко пофильтровать - сагрегировать по регионам. Пока можно. -- Dmitry Kiselev

On Wed, May 06, 2009 at 01:24:41PM +0300, Valentin Nechayev wrote:

...

...

Угу, на RIPE-овке не далее как 10мин назад обсуждали что делать с proposal-ом о multiply /32 v6 allocations for same LIR. Пока ничего не решили, но чтото мне кажется, что policy будет relaxed и LIR-вые /32 можно будет легально де-агрегировать до /24.

Наверное имелось ввиду "...до /48".

А вот скажите про v6 в кабельных сетях - на клиента будет /128, /64 или /48? И интересно сразу же послушать мотивацию такого решения.

http://tools.ietf.org/html/draft-itojun-ipv6-dialup-requirement-02 Я пока смотрю в сторону /64 на клиента. (у меня, правда, PPPoE, а не CATV).

...

И будет тоже самое что с IPv4... :(

А оно и так будет. Экономик-с...

...

Радует только то, что IPv6 PI можно легко пофильтровать - сагрегировать по регионам. Пока можно.

А зачем его фильтровать?

Современные раутеры - hardware-assisted. Причем размер таблицы этого самого hardware довольно таки ограничен. Вспомни историю прошлого года, когда full-view перерос за 256k, и часть кошек (Sup320, [Sup|RSP]720[BC]) оказалась к этому не готова, и перешла по части префиксов с hardware-based forwarding, который она готова исполнять в mpps'ах, на processor-based forwarding, измеряемый в лучшем случае в kpps'ах... А теперь представь себе возможный размер качественно деагрегированой таблицы ipv6. Например, свою /32 я могу деагрегировать на 65536 сетей по /48, 32768 по /47, 16384 по /46 и так далее, в сумме - 128k возможных валидных анонсов. Плюс Вовик свою /32 деагрегирует. :) Вот тебе и 256k префиксов. И см. выше :)

Alexandre Snarskii пишет:

...

...

И будет тоже самое что с IPv4... :(

А что, ожидалось что-то другое? Почему?

А оно и так будет. Экономик-с...

Вот именно. Экономические драйверы для деагрегации не меняются. А технически IPv6 в этом отношении не предлагает ничего отличающегося от того, что мы имеем сейчас в IPv4.

...

...

Радует только то, что IPv6 PI можно легко пофильтровать - сагрегировать по регионам. Пока можно. А зачем его фильтровать?

Современные раутеры - hardware-assisted. Причем размер таблицы этого самого hardware довольно таки ограничен. Вспомни историю прошлого года, когда full-view перерос за 256k, и часть кошек (Sup320, [Sup|RSP]720[BC]) оказалась к этому не готова, и перешла по части префиксов с hardware-based forwarding, который она готова исполнять в mpps'ах, на processor-based forwarding, измеряемый в лучшем случае в kpps'ах...

А теперь представь себе возможный размер качественно деагрегированой таблицы ipv6. Например, свою /32 я могу деагрегировать на 65536 сетей по /48, 32768 по /47, 16384 по /46 и так далее, в сумме - 128k возможных валидных анонсов. Плюс Вовик свою /32 деагрегирует. :) Вот тебе и 256k префиксов. И см. выше :)

Ну, все-таки в IPv4 деагрегация не максимальна (если распилить все анонсированное на сегодня пространство до /24, мы бы видели около 8 млн. префиксов). Нет причин думать, что в IPv6 все вдруг ринутся деагрегировать до предела. В IPv6 *все то же самое* в плане inter-domain routing, что и в IPv4. Поэтому мы очень, очень быстро придем практически к тому же положению, что и с нынешним IPv4 full view.

2009/5/6 Daniel Ginsburg : [..skipped..]

...

А теперь представь себе возможный размер качественно деагрегированой таблицы ipv6. Например, свою /32 я могу деагрегировать на 65536 сетей по /48, 32768 по /47, 16384 по /46 и так далее, в сумме - 128k возможных валидных анонсов. Плюс Вовик свою /32 деагрегирует. :)

Если ты мне расскажешь, как в v6 получить оптимизацию latency без separate/more-specific prefixes - пилить не буду :-)

...

Вот тебе и 256k префиксов. И см. выше :)

Ну, все-таки в IPv4 деагрегация не максимальна (если распилить все анонсированное на сегодня пространство до /24, мы бы видели около 8 млн. префиксов). Нет причин думать, что в IPv6 все вдруг ринутся деагрегировать до предела.

В IPv6 *все то же самое* в плане inter-domain routing, что и в IPv4. Поэтому мы очень, очень быстро придем практически к тому же положению, что и с нынешним IPv4 full view.

Одна халепа - 300K+ v4 prefixes это уже напряжно для некоторых коробок. Еще 300K+ v6 prefixes сверх того и на одной коробке - изрядно много железа менять прийдется. -- Regards, Volodymyr.

On Wed, May 06, 2009 at 02:21:09PM +0300, Dmitry Kiselev wrote:

...

...

...

Радует только то, что IPv6 PI можно легко пофильтровать - сагрегировать по регионам. Пока можно.

А зачем его фильтровать?

Современные раутеры - hardware-assisted. Причем размер таблицы этого самого hardware довольно таки ограничен. Вспомни историю прошлого года, когда full-view перерос за 256k, и часть кошек (Sup320, [Sup|RSP]720[BC]) оказалась к этому не готова, и перешла по части префиксов с hardware-based forwarding, который она готова исполнять в mpps'ах, на processor-based forwarding, измеряемый в лучшем случае в kpps'ах...

А теперь представь себе возможный размер качественно деагрегированой таблицы ipv6. Например, свою /32 я могу деагрегировать на 65536 сетей по /48, 32768 по /47, 16384 по /46 и так далее, в сумме - 128k возможных валидных анонсов. Плюс Вовик свою /32 деагрегирует. :) Вот тебе и 256k префиксов. И см. выше :)

Даже хуже. Для TCAM based platform, например, Sup720/RSP720, IPv4 prefix помещается в 72-bit row, а IPv6 ввиду своего размера требует уже 144-bit row.

Для этих платформ, если мне склероз не врет - даже еще хуже. В 144-bit row у тебя помещаются "короткие" (up to /64) префиксы, а если нужно хранить, например, loopback address с длиной префикса в /128 - это уже два row (и, соответственно, двойной lookup) требуется...

Соответственно, 1 млн IPv4 префиксов заявленных для XL означают всего лишь 512 тыс IPv6. Для non-XL все гозадо грустнее: 256 тыс IPv4 и 128 тыс IPv6.

И то не одновременно :)

Hi Alexandre,

PS: была на каком-то nanog'е хорошая презентация на предмет того, что ipv6 does not scale. И IPv6 PI - это хороший прыжок в сторону того, что оно действительно не будет scalable.

IPv6 PI занимает какую-то очень странную нишу в policy, т.к. подразумевает полное отсутствие клиентов (которое я затрудняюсь представить для конторы любого типа). Соотв-но, непонятно во что это выльется и как это будут использовать на самом деле. -- Michael

Hi Alexandre,

...

Во-вторых в IPv6 нет нормального private space, а /64 - это одна подсеть, таким образом возможности клиента при переходе на IPv6 снижаются :)

Я бы не сказал, что выдавать "юзеру домашнему обыкновенному" более одной подсети - это правильный подход. А именно такие пользователи и рассматриваются обычно в рамках PPPoE/CATV deployments.

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

Добрый день! On Fri, May 08, 2009 at 01:52:30PM +0200, Maxim Tuliuk wrote:

IMHO, тут скорее проблема поставщика, решившего что если на Switch Catalyst 6500 приклеить этикетку Router 7600, то он станет Edge router for ISP.

С другой стороны, сначала продать всем Sup720-3B, а потом Sup720-3BXL, и убедить всех, что во всем виноват "неожиданный рост" - тоже хороший бизнес. ;)

Так, а кто, собственно, заставляет покупать этот Switch/Router? Если он так уж плох покупайте что-то другое у более другого вендора. Либо добивайтесь признания недобросовестного вендора, портящего вам жизнь, монополистом со всеми вытекающими. -- Dmitry Kiselev