[Ivan_83]

Вы продемонстрировали: на платформе с хорошим IP-стеком в ручном режиме можно строить всякие прикольные схемки. Отлично.

Теперь посмотрим, что нужно индустрии. Абонент может подключаться к сети оператора либо непосредственно компом, либо через роутер.

Могу и семёрку на второй роутер поставить, только врядли стоит в серьёз относится к клиентам которые захотят роутить на винде вместо коробок.

 

 

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

Кому сложно?

Вы DHCP видели от винды?

В DHCPv4 от винды всегда есть: "060 - Vendor class identifier: MSFT 5.0"

В DHCPv6 наверняка полно того же самого.

 

Ну и соотвественно выдавать абоненту сразу адрес с его подсети, если там винда - отдавать префикс /64, если не винда то /128 и опцию с делегированием.

Притом можно было бы и всегда /128 отдавать, если точно знать что работать будет.

 

Попробуйте описать какие DHCP опции должен передать Router 1 в сторону Router 2, чтобы то, что вы придумали, заработало.

1. адрес/128

2. делегируемая подсетка /64 (из которой адрес в п1)

В остальном коробка пусть сама конфигурячится:

(с поправкой на в6)

route add -net 172.16.0.254/32 -interface re0 -iface

route add -net 0.0.0.0 172.16.0.254

-тут маршрут 3 в локалку на делегированные адреса через линклокал адрес коробки-

делегируемая подсетка скармливается дхцп серверу.

 

 

Я например очень сомневаюсь насчет вот этого: route add -net 172.16.0.254/32 -interface re0 -iface Если мне память не изменяет, DHCP не позволяет передать маршрут без next-hop. Да и маска /32 навевает сомнения. :)

Я пока могу говорить только за DHCPv4.

Там /32 передаётся без проблем, более того, опция 33 - это роутинг к хостам, те там только /32.

А вот интерфейс передавать и вправду нельзя.

 

В вск ещё раз соберу стенд и проверю

можно ли: route add -net 172.16.0.254/32 -interface re0 -iface

заменить на route add -net 172.16.0.254/32 192.168.0.1

По идее у нас внешний интерфейс уже получил известный IP от дхцп - и привязал его к интерфейсу, и мы можем смело указать что он и есть шлюз по умолчанию...

 

[nnm]

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

Могу и семёрку на второй роутер поставить, только врядли стоит в серьёз относится к клиентам которые захотят роутить на винде вместо коробок.

Здесь я имел ввиду, что абонент может воткнуть Eternet прямо в рабочий комп. И естественно не маршрутизировать.

Определить тип подключения сложно.

Кому сложно?

Вы DHCP видели от винды?

В DHCPv4 от винды всегда есть: "060 - Vendor class identifier: MSFT 5.0"

В DHCPv6 наверняка полно того же самого.

А iPhone, подключенный через L2 WiFi access-point тоже вставляет опцию 60? Я не знаю. Вы скорее всего тоже. Фишка в том, что мы сейчас не можем быть уверены, что всегда распознаем тип абонентского оборудования.

 

Попробуйте описать какие DHCP опции должен передать Router 1 в сторону Router 2, чтобы то, что вы придумали, заработало.

1. адрес/128

Может не заработать или заработать не везде. Как я писал, IETF рекомендует адресовать сегменты не менее чем /64.

route add -net 172.16.0.254/32 -interface re0 -iface

route add -net 0.0.0.0 172.16.0.254

А откуда она узнает, что нужно так конфигурится? Надо-бы маршруты тоже по DHCP передать...

 

Вы пытаетесь решить частную задачу: собрать то, что Вы придумали на каком-то ограниченном наборе софта/железа. А все остальные хотят решать общую: чтобы работало всегда. А для этого нужно просто соблюдать стандарты. Вы можете проверить Вашу схему на Free, 7-ке, и Linux, но это не будет означать, что она будет работать всегда. Схема с двумя префиксами работает всегда.

Изменено 12 февраля, 2011 пользователем nnm

[Ivan_83]

Вы пытаетесь решить частную задачу: собрать то, что Вы придумали на каком-то ограниченном наборе софта/железа. А все остальные хотят решать общую: чтобы работало всегда. А для этого нужно просто соблюдать стандарты. Вы можете проверить Вашу схему на Free, 7-ке, и Linux, но это не будет означать, что она будет работать всегда. Схема с двумя префиксами работает всегда.

Я выше уже говорил: используйте L2, это тоже гарантированно работает везде.

IPoE: абонент подключается к порту и получает адрес /64 по дхцп. Подключает ещё устройства - получают адреса из той же подсети.

Никакого роутинга и пр.

 

В такой схеме клиент сможет поставить себе роутер (только не понятно зачем?), при этом роутер получит себе адрес /64 на ван и будет просто релееть дхцп на прова.

На лан может взять ещё один адрес.

При этом, в таблице машрутизации роутера достаточно сделать метрику для /64 на лан меньше, чем на ван, а метрику до шлюза выставить минимально возможной.

Вся эта логика простая, и реализуется производителем в прошивке.

Но зная как пишут пьяные китайцы - фик знает что у них получится.

[nashvill]

Схема с двумя префиксами работает всегда.

Должна, но, увы, не работает. Посмотрим, что мне ответят в Brocade на этот счет.

Я пару дней назад нагуглил, что на такие же грабли и с кошками народ наступил. Решения тоже не было, видимо и там ждут обновленного firmware.

 

А в остальном, картинка вырисовывается вполне приятная и удобная.

Общий /64 на дом/сегмент и по отдельному /64 на абонента если у него роутер.

Мы для удобства через абонентский ЛК реализовали процедуру "закрепления" блока адресов за абонентом (т.е. по dhcpv6 ему всегда будет выдаваться один и тот же блок).

Пока правда есть небольшая грабля связанная с тем, что мы заранее не знаем клиентский DUID, а матчить клиента по маку я пока не понял как - не могу найти в dhcpv6 соответствующего option.

 

Вы пытаетесь решить частную задачу: собрать то, что Вы придумали на каком-то ограниченном наборе софта/железа. А все остальные хотят решать общую: чтобы работало всегда. А для этого нужно просто соблюдать стандарты. Вы можете проверить Вашу схему на Free, 7-ке, и Linux, но это не будет означать, что она будет работать всегда. Схема с двумя префиксами работает всегда.

Я выше уже говорил: используйте L2, это тоже гарантированно работает везде.

IPoE: абонент подключается к порту и получает адрес /64 по дхцп. Подключает ещё устройства - получают адреса из той же подсети.

Никакого роутинга и пр.

 

В такой схеме клиент сможет поставить себе роутер (только не понятно зачем?), при этом роутер получит себе адрес /64 на ван и будет просто релееть дхцп на прова.

На лан может взять ещё один адрес.

При этом, в таблице машрутизации роутера достаточно сделать метрику для /64 на лан меньше, чем на ван, а метрику до шлюза выставить минимально возможной.

Вся эта логика простая, и реализуется производителем в прошивке.

Но зная как пишут пьяные китайцы - фик знает что у них получится.

Как то вы все пытаетесь втюхать решение не для масс. Вот купил абонент роутер в магазине, принес домой, воткнул и все должно работать.

Абонент роутер поставит себе чтобы подключить ноут по вайфаю, айпад, айфон, комп стационарный, да микроволновку и холодильник в конце концов в будущем. А вы предлагаете поставить коммутатор и всю квартиру проводами устелить?

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

 

А про релеить dhcp на прова я вообще не понял, подробнее эту мысль опишите плиз.

[Lynx10]

Как то вы все пытаетесь втюхать решение не для масс. Вот купил абонент роутер в магазине, принес домой, воткнул и все должно работать.

Абонент роутер поставит себе чтобы подключить ноут по вайфаю, айпад, айфон, комп стационарный, да микроволновку и холодильник в конце концов в будущем. А вы предлагаете поставить коммутатор и всю квартиру проводами устелить?

да нет проблем ставите ап в бридж - и делов то - и нет проводов - короче - не аргумент

 

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

а вот это уже аргумент - но при в6 слабый!

[Ivan_83]

И да, вариант 2, "стандартными" роютами тоже самое.

ИД из предыдущего поста про роутинг, что изменилось я запостил сюда.

 

Шлюз 1 (который с нетом):

route add 192.168.0.1 172.16.0.254
route add 192.168.0.0/24 192.168.0.1


Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            213.228.116.147    UGS         0  5424612    ng0
92.124.14.116      link#3             UHS         0    66999    lo0
127.0.0.1          link#2             UH          0  2266612    lo0
172.16.0.0/24      link#1             U           0 24345410    em0
172.16.0.241       link#4             UH          0      497    ng1
172.16.0.254       link#1             UHS         1        2    lo0
192.168.0.0/24     192.168.0.1        UGS         0      236    em0
192.168.0.1        172.16.0.254       UHS         0      258    em0

 

Шлюз 2:

ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MA
GIC>
        ether 00:1a:4d:55:9a:42
        inet 192.168.0.1 netmask 0xffffffff broadcast 192.168.0.1
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 00:07:e9:2a:6f:5c
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
em1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 00:07:e9:39:2a:d5
        media: Ethernet autoselect
        status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet 127.0.0.1 netmask 0xff000000


route add 172.16.0.254 192.168.0.1                                                                  
route add 0.0.0.0 172.16.0.254 



Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            172.16.0.254       UGS         0      195    re0
127.0.0.1          link#4             UH          0      202    lo0
172.16.0.254       192.168.0.1        UHS         0       69    re0
192.168.0.0/24     link#2             U           0      428    em0
192.168.0.1        link#1             UHS         0        0    lo0 =>
192.168.0.1/32     link#1             U           0        0    re0
192.168.0.2        link#2             UHS         0        0    lo0

 

В данном случае пришлось взять два адреса, по одному на каждый интерфейс, потому что в данном случае IP адреса служили для привязки к физ интерфейсам.

 

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

Кроме того, на линухах вроде есть метрики для маршрутов, это позволит без проблем вешать /64 на оба интерфейса, ставя на ван метрику по больше для /64, и минимальную для дефолт шлюза, а на лан соотвественно минимальну. метрику для полученной /64.

[Ivan_83]

А про релеить dhcp на прова я вообще не понял, подробнее эту мысль опишите плиз.

Роутер клиента, в режиме роутера, может либо сам перераздавать полученный диапазон /64 своим дхцп сервером, либо релееить запросы на дхцп прова.

 

Линкс правильно заметил, роутер стремится к бриджу, ибо в ряде случаев от него требуется функционал свича с фенечками типа выборочного фаерволинга и/или чего то ещё, рынок покажет.

[nashvill]

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

а вот это уже аргумент - но при в6 слабый!

А причем здесь IPv6 или IPv4? Я хочу видеть ОДИН мак на абонентском порту. И уверен, что большинство операторов хочет так же.

 

А про релеить dhcp на прова я вообще не понял, подробнее эту мысль опишите плиз.

Роутер клиента, в режиме роутера, может либо сам перераздавать полученный диапазон /64 своим дхцп сервером, либо релееить запросы на дхцп прова.

 

Линкс правильно заметил, роутер стремится к бриджу, ибо в ряде случаев от него требуется функционал свича с фенечками типа выборочного фаерволинга и/или чего то ещё, рынок покажет.

Для меня остались неясны ряд моментов.

 

Абонентский роутер получил IPv6 адрес, тут все предельно ясно.

Как устройства ЗА этим домашним роутером получат реальные IPv6 адреса из этого же блока из которого адрес и у самого домашнего роутера? Вариант с тем, что роутер становится тупым бриджем не рассматриваем.

 

 

[darkagent]

Как устройства ЗА этим домашним роутером получат реальные IPv6 адреса из этого же блока из которого адрес и у самого домашнего роутера? Вариант с тем, что роутер становится тупым бриджем не рассматриваем.

вобще то в роутерах полноценно поддерживающих ipv6, это уже предусмотрено. насколько я понимаю, посредством "Router Advertisement" и "Router Solicitation". тупым бриджом оно не будет.

тобишь cpe/router получает свой ipv6 префикс, а железки за ним согласуют настройки средствами автоконфигурации - шлют на групповой адрес router solicitation сообщение, и получают от роутера router advertisement сообщение. и все счастливы.

Изменено 14 февраля, 2011 пользователем darkagent

[nashvill]

Как устройства ЗА этим домашним роутером получат реальные IPv6 адреса из этого же блока из которого адрес и у самого домашнего роутера? Вариант с тем, что роутер становится тупым бриджем не рассматриваем.

вобще то в роутерах полноценно поддерживающих ipv6, это уже предусмотрено. насколько я понимаю, посредством "Router Advertisement" и "Router Solicitation". тупым бриджом оно не будет.

тобишь cpe/router получает свой ipv6 префикс, а железки за ним согласуют настройки средствами автоконфигурации - шлют на групповой адрес router solicitation сообщение, и получают от роутера router advertisement сообщение. и все счастливы.

Вы видимо невнимательно всю тему прочитали.

 

Роутер действительно получает свой ipv6 префикс из которого с помощью RA раздает адреса уже устройством к нему подключенным, однако мой роутер должен создать маршрут для этого Ipv6 префикса, иначе трафик до таких устройств не будет бегать до роутера абонента.

 

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

 

===

 

По обновленной информации у кошек это тоже не работало, однако в относительно свежих билдах уже пофиксили и оно работает, так что жду когда фикс дойдет и до оборудования используемого мною вендора.

[Ivan_83]

Абонентский роутер получил IPv6 адрес, тут все предельно ясно.

Как устройства ЗА этим домашним роутером получат реальные IPv6 адреса из этого же блока из которого адрес и у самого домашнего роутера? Вариант с тем, что роутер становится тупым бриджем не рассматриваем.

Можно и не тупым.

Бридж, на котором висит полученный адрес, который может фильтровать.

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

 

 

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

Я вам пытаюсь показать что всё это делается на L2, который прекрасно давно отлажен, а вы пристаёте с маршрутизацией на L3.

Если вы хотите чтобы ваши роутеры л3 "на лету" узнавали о всех извращениях выданных абонентам по дхцп - в рфк написано: используйте другой протокол.

Какой нибудь аналог РИП.

Лично я не вижу проблемы для провайдера сконфигурячить роутер чтобы он сетку /47 выданную клочками куче клиентов искал на определённом порту.

Если оно не подходит - смотрите РИП-о подобные средства динамической маршрутизации и думайте как связать с дхцп/биллингом.

То что вендоры допили что маршруты прописываются автоматом - может сыграть с вами злую шутку: как RIP/ARP/... не обзывай, техники атак не меняются.

Окажется потом что какой нибудь студент рулит всей вашей сеткой как хочет, а вендоры не могут/не сделали ничего чтобы этого не допускать.

[nashvill]

То что вендоры допили что маршруты прописываются автоматом - может сыграть с вами злую шутку: как RIP/ARP/... не обзывай, техники атак не меняются.

Окажется потом что какой нибудь студент рулит всей вашей сеткой как хочет, а вендоры не могут/не сделали ничего чтобы этого не допускать.

Так как мой роутер выступает в роли dhcp relay, то лишь ту подсеть, которую выдали клиенту и чей ответ на запрос он форварднул (получил от dhcp сервера) он и пропишет в таблице маршрутизации.

Не вижу никаких потенциальных видов атак, которые можно применить в таком случае.

 

Да и зачем мне L2? У меня на L2 коммутаторы знать не знают про ipv6.

 

Раз предусмотрена по RFC выдача отдельного блока для устройств за домашним роутером, то этот вариант и надо использовать.

Изменено 14 февраля, 2011 пользователем nashvill

[inkelyad]

Роутер действительно получает свой ipv6 префикс из которого с помощью RA раздает адреса уже устройством к нему подключенным, однако мой роутер должен создать маршрут для этого Ipv6 префикса, иначе трафик до таких устройств не будет бегать до роутера абонента.

Отдавать абоненту /56 для его внешнего интерфейса (маршрут прилагается) и потом пусть роутер абонента вырезает /64 для своих внутренних портов как хочет?

Изменено 14 февраля, 2011 пользователем inkelyad

[Ivan_83]

Так как мой роутер выступает в роли dhcp relay, то лишь ту подсеть, которую выдали клиенту и чей ответ на запрос он форварднул (получил от dhcp сервера) он и пропишет в таблице маршрутизации.

Не вижу никаких потенциальных видов атак, которые можно применить в таком случае.

Внедряйте, потом посмотрите, расширите кругозор :)

С дхцп в4 понятно - там всякие фичи есть чтобы в магистрали только к/от дхцп серверу пакеты ходили. Для дхцп в6 вы уже оттестили такие средства? А для ND, по которому маршруты передаются?

 

Да и зачем мне L2? У меня на L2 коммутаторы знать не знают про ipv6.

На кой вам в локалке L3 вообще сдался?

Пусть коммутаторы на L2 всё маршрутизируют на wirespeed, L3 адреса чисто как алиас для L2 нужен софту юзера, пока траф в своей сети.

 

Раз предусмотрена по RFC выдача отдельного блока для устройств за домашним роутером, то этот вариант и надо использовать.

В ICMPv4 тоже много чего предусмотрено, скажите честно, вы кроме эха и дст анрич что нибудь ещё разрешили?

[nashvill]

Роутер действительно получает свой ipv6 префикс из которого с помощью RA раздает адреса уже устройством к нему подключенным, однако мой роутер должен создать маршрут для этого Ipv6 префикса, иначе трафик до таких устройств не будет бегать до роутера абонента.

Отдавать абоненту /56 для его внешнего интерфейса (маршрут прилагается) и потом пусть роутер абонента вырезает /64 для своих внутренних портов как хочет?

а будет ли абонентский роутер это (вырезать) делать?

[inkelyad]

Отдавать абоненту /56 для его внешнего интерфейса (маршрут прилагается) и потом пусть роутер абонента вырезает /64 для своих внутренних портов как хочет?

а будет ли абонентский роутер это (вырезать) делать?

А почему не будет? LAN (Абонентская) настраивается же. Либо руками, либо по DHCP(как у вас). У вас же было проблема создать маршрут для сети абонента.

А если вы маршрутизируете на него 2001:db8:1111:aa00::/56 и внутри ставится 2001:db8:1111:aa00::1/64, то все отлично смаршрутизируется. И никаких дополнительных маршрутов создавать не надо.

 

Выглядеть это толжно так:

Есть у вас L2 сегмент. Вы на него выделяете /48 подсеть. Скажем, 2001:db8:1111::/48

На интерфейсе маршрутизатора ставим 2001:db8:1111::1/48

Там же на постоянной основе прописываем маршруты на подсети /56

2001:db8:1111:0100::/56 via 2001:db8:1111:0100::1
2001:db8:1111:0200::/56 via 2001:db8:1111:0200::1
..
2001:db8:1111:aa00::/56 via 2001:db8:1111:aa00::1
..

И теперь абонентам в сегменте выдаем адреса с шагом /56

те

2001:db8:1111:0100::1/48
2001:db8:1111:0200::1/48
...

Подсети /64 вида

2001:db8:1111:xx00::/64
2001:db8:1111:xx01::/64
..

используются внутри LAN абонента.

Изменено 15 февраля, 2011 пользователем inkelyad

[none7]

На кой вам в локалке L3 вообще сдался?

Изоляция своего широковещательного трафика это безопасность. Как ещё сетевые черви в соседней локалке узнают о существовании узлов в соседних сетях? 2^64 адресов фиг отсканируешь. Трафик клиента проще фильтровать при наличии фиксированной приставки, Ваш подход вообще позволит фильтровать 20 узлов на порт? Можно делегировать обратную зону в DNS, хотя никто из провайдеров этого делать не хочет. С каждым днём группового трафика от клиентов в L2 сети будет становится всё больше. Клиенту будет сложнее отделить свой локальный трафик от внешнего. Нет необходимости в логировании занимаемых адресов для органов правопорядка.

 

[inkelyad]

Если верить базовым документам, то для IPv6 вообще обещали снижение расходов на маршрутизацию.

Ждем, когда соответствующие чипы сделают. Без NAT-ов и Firewallов. Чистая wirespeed маршрутизация IPv6. У будет тогда провайдерский маршрутизатор="розетка с интернетом" прямо у абонента в квартире стоять.

[nashvill]

А почему не будет? LAN (Абонентская) настраивается же. Либо руками, либо по DHCP(как у вас). У вас же было проблема создать маршрут для сети абонента.

А если вы маршрутизируете на него 2001:db8:1111:aa00::/56 и внутри ставится 2001:db8:1111:aa00::1/64, то все отлично смаршрутизируется. И никаких дополнительных маршрутов создавать не надо.

Стоп. Так при вашем варианте все что я хочу сделать автоматом вы предлагаете мне сделать заранее руками. Не вариант.

 

Подожду лучше прошивку, чтобы работало как должно, а не через ж*пу к звездам на базе тысяч статических маршрутов.

Изменено 16 февраля, 2011 пользователем nashvill

[inkelyad]

Стоп. Так при вашем варианте все что я хочу сделать автоматом вы предлагаете мне сделать заранее руками. Не вариант.

Не вижу проблемы. Эти все маршруты дальше маршрутизатора сегмента все равно не уйдут.

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

Разумеется, статические маршруты не руками делать надо. Для этого скрипты есть.

 

[Ivan_83]

Изоляция своего широковещательного трафика это безопасность. Как ещё сетевые черви в соседней локалке узнают о существовании узлов в соседних сетях? 2^64 адресов фиг отсканируешь. Трафик клиента проще фильтровать при наличии фиксированной приставки, Ваш подход вообще позволит фильтровать 20 узлов на порт?

Это я когда в институте первые програмки-чаты писал они сканировали перебором, теперь будут новые, интересные способы :)

Броадкастом они у меня не искали, после перебора в первых версиях был мультикаст в последних.

Вот например, приджойница к мультикаст адресам дхцп серверов, релеев и просто насобирать всё что нужно, а можно и навыдавать.

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

Фильтруйте по приставке, а L2 будет мимо ходить :)

Если у вас 20 узлов в порту то между собой они и так будут общаться. Ну повесите вы L3 фильтр а порт, что с него разрешены только адреса из такой то подсети, это хорошо и правильно. Главное не забывать что кроме IP, IPv6 есть и другие протоколы. А то студент предприниматель поднимет у себя пппое сервер и будет продавать свой инет всем подряд без вашего ведома.

 

 

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

На кой она клиенту?

 

Клиенту будет сложнее отделить свой локальный трафик от внешнего.

Локальный это который идёт не через шлюз - что сложного?

[none7]

Броадкастом они у меня не искали, после перебора в первых версиях был мультикаст в последних.

Вот например, приджойница к мультикаст адресам дхцп серверов, релеев и просто насобирать всё что нужно, а можно и навыдавать.

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

Вот по этому клиенты не должны видеть мультикаст соседей. Пусть ходят через L3 и видят в L2 только железки провайдера.

 

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

Другие протоколы пусть рассылает в своей локалке, а провайдерскую нефиг захламлять.

 

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

На кой она клиенту?

Для чего вообще существует PTR запись? Для удобства администрирования.

[darkagent]

Для чего вообще существует PTR запись? Для удобства администрирования.

Большинство почтарей отфутболивает при некорректной или отсутствующей PTR. покрайней мере справедливо для ipv4.

[Ivan_83]

Вот по этому клиенты не должны видеть мультикаст соседей. Пусть ходят через L3 и видят в L2 только железки провайдера.

L3 порт на клиента дорого выйдет.

Если давать L2 вланом и терминировать вланы где то на писюке кучей сразу то локала на скорости порта не будет.

Проще/дешевле писать фильтры для L2 в коммутаторы.

Фильтры там банальные: запретить все типы эзернет фреймов кроме: ипв4, ипв6, апр...и чего то там ещё, по памяти не скажу.

Запретить форвард пакетов с выставленным битом мультикаста (мультикасты и броадкаст).

Это сильно осложнит жизнь "не стандартным" пользователям сети.

Остальное или коммутатор должен будет делать, вроде арп инспекшина или ждать от вендора/забить.

 

 

Другие протоколы пусть рассылает в своей локалке, а провайдерскую нефиг захламлять.

Не спросят, если не заблочить.

[inkelyad]

L3 порт на клиента дорого выйдет.

Сотовые операторы продают свои G3 модемы по <1000 рублей вместе с тарифом. Сделать брендовою L3 "розетку" для проводных линий и делать так же вполне можно.

И потом экономить на мозгах коммутаторов доступа/агрегации. Другое дело, что сейчас на это уже никто не пойдет.