Здравствуйте,

При очередном тестировании IPv6 стало понятно что коммутатор не вносит в IPMBv6 таблицу префиксы, выданные на клиентский маршрутизатор с помощью DHCP. Планируется ли добавление такого функционала? Как мне кажется, без него смысла в IPv6 особо нет, не натить же на клиентских маршрутизаторах IPv6 трафик...

Описание подобной технологии у cisco (IPv6 Prefix Guard): http://www.cisco.com/c/en/us/td/docs/io ... 2A59C9FED3

И Вам не хворать.

Недавно сам создал похожую тему: viewtopic.php?f=2&t=165782
Ответа, как можно видеть, не получил. Тогда я написал письмо на саппорт длинка с теми же самыми вопросами и вот что мне ответил Denis Evgrafov:

1. Это можно реализовать при помощи ACL.
2. Также реализуется при помощи ACL или с использованием IMPBv6.

Чуть более развёрнутый ответ (после непродолжительной переписки):

...этот функционал запланирован, но он не является приоритетным, потому что задачу можно решить при помощи ACL. В будущих версиях прошивки он должен появиться, но пока точные сроки неизвестны.
Одновременно IPv6 и IPv4 связки использовать не получится. Подсети /64 и /48 также не поддерживаются в IMPB.

Защита инвестиций, только не наших, а Dlink.

Это конечно шутка. Но IPv6 делать нужно будет все равно. У кого какие мысли как это делать без IPMBv6?

Попробую сделать /128 с помощью IPMBv6 + /64 в отдельном access_profile статикой в конфиге

To: prx
Обратите внимание на то, что: Одновременно IPv6 и IPv4 связки использовать не получится.
Если Вы сделаете /128 на основе IMPBv6, то не сможете использовать IMPB для ipv4 (как я это понимаю). То есть, если Вы используете ipv4, то его привязку тоже надо будет делать через ACL-правила. Это, на мой взгляд, неудобно. Если же Вы будете ипользовать ipv6-only сеть, то прошу, поделитесь с общественностью - где же такая сеть на данный момент имеет место быть и с какой целью эксплуатируется, если это конечно не секрет.

vlan per customer решает эту проблему. и не только её

Ну, во первых, такая схема неплоха, но, как Вы понимаете, есть не у всех провайдеров по различным причинам. А во вторых - как, даже в такой в такой схеме, защитится от подмены клиентом ip адреса?

Когда каждый клиент в своём влане, то при подмене клиентом ip-адреса у подменившего просто перестанет работать сеть.

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

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


Это смотря как он подменит, вполне возможно что и вашу положит. Я тут проводил эксперименты с подстановкой неправильных source ip в пакет, результаты, должен сказать, интересные. Отловить такого вредителя очень непросто (правда есть функционал на L3, но у нас он дико жрет проц). Так что блокировать разные безобразия надо еще в самом начале.

_________________
D-Link Switches: Tips & Tricks

Пример.
Есть два клиента - во вланах 10 и 20 соответственно.
На первого клиента на провайдерском роутере раздаются по dhcp адреса 192.168.10.x, на второго 192.168.20.x.
Если первый клиент вместо получения адреса по dhcp поставит себе вручную ip-адрес из диапазона второго клиента, то роутер перестанет видеть первого клиента, т.к. он даёт arp-запросы на 192.168.20.x во влан 20, и на появление такого адреса во влане 10 не обратит внимания. Конфликтов ip-адресов со вторым клиентом также не будет, т.к. клиенты в разных вланах и трафик друг друга напрямую не видят.
Даже более того - проблем не будет даже при совпадении mac-адресов.

Ровно точно так же работает и ipv6 адресация, параллельно с ipv4 (dual-stack).
Для выдачи абонентам внешних ipv4 адресов используется маршрут-на-интерфейс, что позволяет расходовать их штучно (/32).

Отдельные экземпляры вредителей могут попытаться отправлять пакеты от адреса соседа, что может использоваться, например, для обрыва его tcp соединений. От этого спасает настройка провайдерского роутера, запрещающая приём трафика с адресов, куда не маршрутизируется этот трафик. Т.е. если в сторону абонента смотрит direct route 192.168.10.0/24 - то пакеты от клиента также принимаются только с адресов 192.168.10.x - пакеты с любым другим адресом источника будут отброшены файрволом.
Также это помогает от источников DDoS атак типа ntp-amplification.

p.s.
всё это не теоретические измышления. Эту схему я применяю уже лет десять на практике. Всё прекрасно работает.
При этом на доступе у меня кое где до сих пор стоят даже древние DES-3226S, и будут работать и далее - до полной выработки ресурса. От свича в общем случае требуются только вланы.

Речь про Unicast Reverse Path Forwarding (uRPF)? Что за железка является роутером? Наши Foundry (Brocade) не справляются.

_________________
D-Link Switches: Tips & Tricks

Спасибо за ответы, благородные доны.
Я разделяю точку зрения xcme о том, что "Самое начало", в моём понимании, это порт оборудования в который подключено CPE абонента, т.е. доступ.
Уважаемый RDC, как я понимаю, осуществляет блокировку и фильтрацию на более высоком уровне. Ну что тут сказать - возможность выбора это всегда хорошо.

To RDC:
1. На чём терминируете виланы, кошка?
2. "Запрет приёма трафика с адресов, куда не маршрутизируется этот трафик" - тоже, как я понимаю, цисковская фича.

IPv6-only пока применять невозможно, пользователи разбегутся

На тестовом коммутаторе вроде бы работает, но пока еще не все проверил. IPv4 заносятся в ProfileID 513:
Profile ID: 513 Profile name: IMPB v4

MASK on
Source MAC : 00-00-00-00-00-00
Ethernet Type
Source IP : 0.0.0.0

А IPv6 в Profile 514:
Profile ID: 514 Profile name: IMPB v6

MASK on
Source MAC : 00-00-00-00-00-00
Source IPv6 Addr: ::


Но все это не имеет смысла, так как IPMBv6 блокирует делегированные префиксы.

А какую подсеть per-vlan используете? Применяете ли QinQ?