[s.lobanov]

Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступе

Именно!

И позволяет использовать самые дешёвые решения для доступа, типа DES-1228/ME, от которых ничего кроме dot1q и не требуется вовсе.

 

Ну ещё надо иметь возможность ограничивать кол-ва мак-адресов с порта, чтобы один абонент не мог переполнить fdb и тем самым мешать нормальной работе соседей по свитчу. Ещё mvr тоже не плохо бы иметь, но его можно сделать и на уровень выше.

[rdc]

Ну ещё надо иметь возможность ограничивать кол-ва мак-адресов с порта, чтобы один абонент не мог переполнить fdb и тем самым мешать нормальной работе соседей по свитчу.

Да, точно.

Ещё полезно автоотключение порта по петлям и штормам.

mvr тоже не плохо бы иметь, но его можно сделать и на уровень выше.

Вот-вот.

[iten]

есть варинты без "влан на клиента" и без CPE?

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

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

[rus-p]

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

Посчитал тут на досуге и вышло, что у пары вендоров, выход как-то и не просматривается. Денег выходит сопоставимо с ценой порта на коммутаторе доступа, порядка 10$ с носа, а возможности самого мощного железа едва дотягивают до 50к онлайн клиентов. Что самое интересное, для тех компаний, кол-во клиентов у которых несколько менее 50к, это железо вообщем-то не подъемно.

[ipaddr.ru]

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

Я что-то не понял, о каком нате речь? Мы вроде о native ipv6 говорим, ну в крайнем случае 6rd.

[ingress]

Вариант экономии адресов IPv4

(не внедряя NAT оставляем белые пулы адресов у клиентов повышая при этом эффективность утилизации)

 

http://tools.ietf.org/html/draft-fleischhauer-ipv4-addr-saving-01

 

Должен поддерживать CPE и BRAS.

[ipaddr.ru]

Ну, во-первых, вне топика, а во-вторых, это ж СТРАУС!

[rus-p]

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

Я что-то не понял, о каком нате речь? Мы вроде о native ipv6 говорим, ну в крайнем случае 6rd.

 

Ну как бы внедрение IPv6 подразумевает резкое наращивание мощности NAT.

Вы же понимаете, что контент не переедет в одночасье и за год не переедет.

6rd спасает для доступа к v6, но не к v4.

У крупного оператора в России за год может набраться от 50.000 до 1000000 новых клиентов.

На чем делать будем ?

[rm_]

Ну как бы внедрение IPv6 подразумевает резкое наращивание мощности NAT.

Неправильно. Исчерпание v4 подразумевает наращивание мощности NAT, это да. А вот внедрение v6 как раз-таки снижает нагрузку на этот NAT, поскольку нехилая часть трафика уходит с NAT44 на незаначенный v6 (те же торренты и ютуб). Кроме того, вы ведь в курсе, что внедрение v6 не подразумевает "вывнедрения" v4?

[rus-p]

По существу вопроса есть мысли ?

[rus-p]

Вариант экономии адресов IPv4

(не внедряя NAT оставляем белые пулы адресов у клиентов повышая при этом эффективность утилизации)

 

http://tools.ietf.org/html/draft-fleischhauer-ipv4-addr-saving-01

 

Должен поддерживать CPE и BRAS.

 

Будет ли эффективен такой подход?

dhcp и так повсюду, ну или пулы в радиусе или прямо на NAS если что-то ppp-шное.

Абоненты, в массе своей, втыкают CPE который не рвет сессию. Так и висят все эти адреса, как будто по ночам никто не спит.

Плюс проблемы хостингов, которым по зарез нужно максимально долго присутствовать в обоих версиях идут в разрез с желанием иметь ipv6 only интернет.

[ipaddr.ru]

Вот как раз у хостингов я проблем не прогнозирую.

[rus-p]

У хостингов, да, особых проблем не предвидится, а вот необходимость ему, хостингу, держать до последнего обе версии протокола, породит проблемы у провайдеров, т.к. трафик v4 будет долго сохраняться, а с ним и NAT.

[karpa13a]

У хостингов, да, особых проблем не предвидится, а вот необходимость ему, хостингу, держать до последнего обе версии протокола, породит проблемы у провайдеров, т.к. трафик v4 будет долго сохраняться, а с ним и NAT.

ммм, так у кого проблемы то будут?) и из-за кого?

[ingress]

Будет ли эффективен такой подход?

dhcp и так повсюду, ну или пулы в радиусе или прямо на NAS если что-то ppp-шное.

Абоненты, в массе своей, втыкают CPE который не рвет сессию. Так и висят все эти адреса, как будто по ночам никто не спит.

Плюс проблемы хостингов, которым по зарез нужно максимально долго присутствовать в обоих версиях идут в разрез с желанием иметь ipv6 only интернет.

 

будет, когда трафик сместится в IPv6, а IPv4 будет требоваться только от legacy сервисов, типа www, которые по требованию идут, когда пользователь активен, в остальное время(спустя таймаут) CPE может отдать обратно свой IPv4 адрес.

DHCP(IP/IPv6oE) в головах у конкретных вендоров, в мире у большинства broadband операторов PTA.

 

p.s. посмотрите кто написал драфт, тому оно и надо.

наверно считают такой подход эффективным и не хотят городить фермы блейдов с NAT.

[rus-p]

На вскидку, предложенный драфт внедрят в CPE когда блоков уже не останется, тогда как он нужен текущим подключенным пользователям, что бы появились свободные блоки из этой идеи. Поэтому даже те у кого PTA упрутся в несколько лет оборачиваемости CPE/софта на нем.

 

А вообще идея выглядит лучше, чем сидеть и ждать пока графики загрузки NAT стабилизируются и пойдут вниз.

kapa13a, только не говорите, что у вас PTA, вы давно все рассчитали и теперь сидите потираете руки, видя как тужатся конкуренты выжимая из недр акционерных обществ деньги нат )

Изменено 14 сентября, 2011 пользователем rus-p

[karpa13a]

, только не говорите, что у вас PTA, вы давно все рассчитали и теперь сидите потираете руки, видя как тужатся конкуренты выжимая из недр акционерных обществ деньги нат )

я к тому, что хостинги, если дадуд в6, то нужда в в4 отпадет (быстро начнет снижаться. должна) ) у ендюзера.

как только начнет нормально (а не как сейчас 5ю вариациями) отдаваться в6 ендюзеру.

даже сейчас, дав в6, п2п туда уползет а это дай бог 50% минимум.

 

так что при попытке напряч топа на бабло для ната, техдира под попу на улицу, гика - внедрять в6 на сети)

 

пс втф "PTA"?

[rus-p]

 

я к тому, что хостинги, если дадуд в6, то нужда в в4 отпадет (быстро начнет снижаться. должна) ) у ендюзера.

как только начнет нормально (а не как сейчас 5ю вариациями) отдаваться в6 ендюзеру.

даже сейчас, дав в6, п2п туда уползет а это дай бог 50% минимум.

 

так что при попытке напряч топа на бабло для ната, техдира под попу на улицу, гика - внедрять в6 на сети)

 

пс втф "PTA"?

 

ключевое слова "должна" )

т.е. производители браузеров должны выпустить патчик, и предложить его установить, чтобы их браузер резолвил сначала v6, а потом v4.

Думаете они так рискнут ?

Проще галку иметь, но не включать по умолчанию, тогда подавляющее большинство так и будет ходить по v4.

 

Каким образом 50% уползет, если все текущие IPv4 адреса так и будут продолжать жить ? Суммарно P2P v6 конечно пойдет вверх, но вот его доля v4, не уверен, что начнет падать.

 

PTA, это способ терминации клиентов на брасе - PPPoverX, в топик ввел ingress )

[karpa13a]

производители браузеров должны выпустить патчик

какой процент от общего трафика это ввв?)

 

на счет галок, мозилла уже сейчас ищет сначала АААА а потом только А(подефолту галка включена).

если А нету то идем в в6. если и то и другое, то в зависимости от операционки. (как в ие невкурсе)

в4 преферед над тунелями (от операционки зависит).

 

рфц 3484 уже поминался в этом топике.

[Картуччо]

Добавил в браузер индикатор v4/v6.

Практически ни один из ведущих производителей сетевого оборудования не удосужился свой сайт сделать доступным по IPv6. То же самое с гигантами программного обеспечения.

Чего уж говорить про обычный контент.

[ipaddr.ru]

Обычный контент, кстати, встречается. И чаще всего, по моему опыту, встречаются неймсерверы с IPv6.

[Tima]

А есть ли _красивый_ аддончик под ff, который бы показывал v4/v6 статус ?

[Картуччо]

http://www.hunen.net/4or6/

https://addons.mozilla.org/en-US/firefox/addon/4or6/

У меня вот этот. Ограничился иконкой в url-bar: 4 на красном фоне это только v4, 6 на зеленом фоне это 4 и 6, 6 на синем фоне это только 6.

[rm_]

https://addons.mozilla.org/en-US/firefox/addon/ipvfox/

Единственный аддон, который смотрит, с какого адреса в действительности получен контент, а не просто на DNS-записи.

Но как побочный эффект - он бесполезен использующим прокси.

[Tima]

http://www.hunen.net/4or6/

https://addons.mozilla.org/en-US/firefox/addon/4or6

 

Либо он в 7.1 не работает, либо я тупой. Ничего он мне не показывает.

 

 

ipvfox заработал, спасибо! :)