vop

Какой? Какой месячный объем предполагается?

Я покушал, потянуло на творчество. Кстати, подскажите, как отключить этот слишком умный редактор на локале? 1. Во первых, никакие маки не маршрутизируются. Никто не будет роутить префиксы, длинее /64. Ну, разве вы у себя локально будете расбрасывать. Во вторых, там содержатся поля маков только в некоторых случаях (!!!), только при определенных ситуациях (!!!). Более того, адрес, в котором зашит мак, является приватным, и "нвружу" не выходит. Для ходьбы наружу автоматически генерируется случайны адрес без сигнатуры мака, которым клиент и ходит в мир. Казалось бы, сложно.... Но плат

slaac В этих 64 битах зашито, например 48 бит MACадреса и 16 бит - сигнатура (ибо там slaac не только на езернетах работает). Плюс - анонимизация. И интернет делался не для списков блокировок.:) Переход на v6 делается совсем просто. Сервера садятся на дуал-сетк. Делается это 15 минут без специальных знаний и затрат. А клиенты переводятся на v6, и с единственнымv6адресом имеют доступ к обоим протоколам. Просто все ленивые.

Что-то я как-то бестолково пишу. Сходил, покушал. Решил дополнить. Представьте ситуацию. Вы покупаете ether-какрту. А продавец говорит, что, мол, там есть MAC-адрес, за него надо заплатить. И более того, надо ежегодно оплачивать его использование... Странно, что никто еще не додумался торговать MAC-ами. Потому, что MACи - это абсолютно технологический компонет, вокруг которого нет никакого фетиша. Вот если вы производите сетевое оборудование, то тут уже другой вопрос - вам необходимо получить свой mac-префикс. Или прикинуться китайцем Введение ipv6 так же подкинуло

У меня сейчас три аплинка (хотя я не провайдер). Они вообще не дают ipv6. Но я нашел двух провайдеров ipv6 для "личных нужд" - мне хватает. Я не знаю, что делать провайдерам. ipv6 развивать надо, что бы не "застали врасплох". Вопрос не в бесплатной раздаче, а в ipv6, как свойстве предоставления линка. Возможно в рамках стоимости самого линка. Сущность ip адреса меняется в v6. Но это, как я понимаю, вопросы, которые продолжают дискутироваться. Как бы новые возможности открылись, а применить их с толком и красотой пока не понятно, как. По второму - ничто так не умножает

1. Первый абсурд - это попытка торговать префиксами так же, как торговали сетками в ipv4. Этот товар не стоит столько. И не должен столько стоить. Пока будут пытаться продавать - ipv6 будет тормозиться. 2. Речь не идет о NAT'е. Речь идет о трансляции 1в1 Никаких таблиц коннектов держать не надо, адресов достаточно. Не нравится - есть другие варианты. 3. И речь идет о совершенно другой идеологии, при которой сетки не растаскиваются в рамках PI, а держаться "кучками". Никто не будт таскать/48 по разным роутингам. Поэтому, когда IRы "проникнутся" новыми идеями, тогда дело и

Это один из вариантов multihomed ipv6. Вот тут немного подробнее: https://en.wikipedia.org/wiki/Multihoming#IPv6_multihoming В любом случае, обычный классический подход народу не очень нравится из-за огромных таблиц роутинга. В ipv6 действительно все проще. В первых, ip в этой версии иммет более "утилитарное" значение, так-как запоминать его просто неразумно, держаться за свой "адрес" глупо, и оперировать надо в основном доменом, который в ipv6 должен перестраиваться динамично, в случае с рутингвыми траблами (как - фиг его знает). А во вторых - адресов доста

https://tools.ietf.org/html/rfc6296 Если вы ISP, даете доступ клиентам, то берете несколько префиксов от каждого uplink'a. Ну и транслируете.

Там надо почитать. Насколько я помню, на выдачу ipv6 устанавливали другую политику выдачи блоков, и провайдерам теперь не выдают PI. https://www.ripe.net/publications/docs/ripe-707 Я не запрашивал, поэтому это только то, что вертится в голове.

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

Да там особо сложного ничего нет. Мне была интересна мультимаршрутность и устойчивость протокола. Сделал, протестировал, и отложил в сторону. Будут просьбы - буду включать. Актуален, например, для биллингов, при установке их в облаке "у черта на куличках".

У меня в сырцах агента сейчас это выглядит так: (*in_soc)->proto = IPPROTO_TCP; // Or IPPROTO_SCTP Комментарий там появился достаточно давно, после того, как я устал объяснять, что это за опция в конфиге. Никому "оно" не надо. Мало кто понимает, зачем оно надо. Работает нормально.

Знаете, что называют "котылями"? В ситуациях, когда задачу нельзя решить стандартными способами, придумывают нестандартный, с нарушением принятых протоколов. Обычно "костыль" решает определенную задачу, иногда даже не плохо, до определенного момента, в который стандартная мера могла бы справится сама. Работа с оцией 82 может быть какой угодно - даже на "побочных эффектах", но я бы назвал это каким-нибудь другим словом, а не "реализацией dhcp". И что бы не вставать два раза: Называется "развивать победное наступление" Дружище, мне, честно

Я вас услышал. Вы - о своем. Ну да ладно, не важно.

Вы сейчас описали совершенно другую ситуацию - другой MAC в тот же порт. А мы обсуждали ситуацию одного и того же MAC'а в другой порт. У Ивана сделано немного по другому. Он просто исполняет отказ от лизы и выдает новую. А опция 82 используется опять же для выбора политики выдачи ip адреса, точно так же, как и любые другие сервера. Немного грубо, и не совсем чисто, но для всех общих случаев подойдет.

Я про таких не слышал. Не подскажите, о каких реализациях идет речь? Те, немногие dhcp сервера, которые я в свое время пробовал, всегда продлевают ту же лизу даже при смене opt 82. Так-как это вообще не дело dhcp сервера их отслеживать. Пришла опция - выбрал политику выбора пула (если админ настроил его на это "беспокойство"), и забыл. Все остальное - это дело свича, как реагировать, на ответ с "неправильной" опцией 82 (для чего она, собственно говоря, и придумывалась). Большинство железа на это никак не реагирует. По большому счету, если эта опция не используется для защиты от те

Там не новый мак у Пети будет. Там будет Васин мак с другой опцией 82. Просто напомню, dhcp сервер выдает и хранит лизы по мак-адресам, и никак иначе. И если биллинг не следит за парами mac/82 - то начнется компот и "внеземные цивилизации".

Я передам ваши слова ребятам из райцентра... Хотя, я им уже давно сам все объяснил и пояснил.

По этому поводу провайдер сказал что-то типа - а вдруг абон поставит свою онушку, зарегистрирует ее, а мы потом мучайся.:) Ну я особо не настаиваю. Мое дело предложить, а дело провайдера - выбрать так, как ему удобно...

(Анекдот) У логопеда: - Доктор, я плохо выговариваю букву Ч? - Ну как же, дружище! Совсем даже не плохо выговариваете! - Ну не чавчем.:) И так, схема такая. В одном месте оказываются человек и розетка (та, которую когда-то поставил монтажник). Просто не забываем, что в цивилизованном случае в квартире у человека электрические и ethernet розетки изначально давно установлены и куда надо подключены. Человек втыкает что-то интернет-кушающее в розетку. 1. Этот этап пропускам в описании, так-как для Украины не актуально (интеграторы последней мили в стране не прижилис

Немного странно. У меня такая процедура потребовалась в Киевстаре только один раз, когдау них "паламался" свич, и они меня переткнули в другой. MAC (DUID) нужен всегда, так-как это основной id, на котором работает dhcp. Если порт висит в воздухе, то при подключении устройства DHCP выдает неизвестному MAC'у свободный адрес из пула (зачем его потом менять - неизвестно). Потом смотрит, на каом порту висит этот мак по opt82. И только после того, как клиент ввел свои кредиты, порт "закрепляется" за клиентом, и в дальнейшем все другие маки, пришедшие с этого порта, будут числиться за эт

Наверно я плохо описал, зачем. Для идентификации подключения клиента. optiоn 82 замечательно идентифицирует как порт подключения, так и vlan. В природе есть два способа идентификации физического подключения: 1. Монтажник записал на сигаретной пачке. 2. Клиент ввел свои id/secret. Других, как бы не существует. В первом случае 82-ю опцию часто используют для определения политики выбора пула в dhcp. Как и vlan. Тут действительно или vlan или opt82. Одновременно они не нужны. Нужно только заранее знать, кому принадлежит порт, или vlan. Но это "ручная бумажная техн

Ну если не поддерживается, то и ладно, можно без него. Я в свое время взялся писать софт под провайдера, с академической целью убрать максимально человеческий труд, там где он не нужен. Давно придумал схему, в которой офис для клиента совсем не нужен, реализовал. Но, похоже, никому "оно не надо". Или просто я плохо доношу свою мысль до коллег. Option 82 была придумана вообще, как механизм защиты от атак на DHCP из untrusted segments. Ну, поскольку она стала удобной для работы в крупных сетях, в том числе и провайдерской, то почему бы ее не использовать. Ест

О! Вот оно. Именно при vlan-per-user оно очень полезно. Ежели, конечно, линейное оборудование умеет рассказывать про option 82.

И да, там нет arp, ибо нет broadcast. Соответственно, нет arp proxy, бо не надо. Есть ndp. Иногда он весьма забавные вещи дискаверит.