Добрый день! On Wed, May 06, 2009 at 02:54:45PM +0400, Alexandre Snarskii wrote:
А вот скажите про v6 в кабельных сетях - на клиента будет /128, /64 или /48? И интересно сразу же послушать мотивацию такого решения.
http://tools.ietf.org/html/draft-itojun-ipv6-dialup-requirement-02 Я пока смотрю в сторону /64 на клиента. (у меня, правда, PPPoE, а не CATV).
+1, но до deployment пока еще далеко.
Радует только то, что 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. Соответственно, 1 млн IPv4 префиксов заявленных для XL означают всего лишь 512 тыс IPv6. Для non-XL все гозадо грустнее: 256 тыс IPv4 и 128 тыс IPv6. -- Dmitry Kiselev