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 префиксов. И см. выше :)