vop

А как обычно. Для этого префиксы не нужны. По большому счету, и адреса не обязательно нужны. Все остальное - как обычно - ipoe, pppoe, и т.д. В ipv6 есть смысловое отличие между устройством и роутером. Роутерам обычно не разрешают самоназначать адрес. В общем, и сами устройства адрес не смогут назначать, если им не разрешит роутер, который рассылает адвертисменты по мультикасту. В общем, выбирайте вариант, какой душе угодно.

Ну не жалко же...:) просто для одноранговой сети придумали протокол автоматического конфигурирования без какого-либо дополнительного софта. А у клиента дома именно такая сеть обычно и есть. Для этого грохают /64. Для других случае такие префиксы не нужны. Иногда вообще никакие адреса не нужны. Вот представьте, сколько на земле всего адресов v4...Вот теперь столько же префиксов /32

Ну вот если взять простой роутер, то у него есть, как минимум, 2 интерфейса - провод и wifi. Вот уже как бы надо два префикса под слаак. В ipv4 делают бридж на них. В v6 как бы неприлично это делать. Да и смысла нет, ибо в v6 нет бродакаста.

Вот тут предлагают за10 евров в месяц. 2 терабайта хранилище. 10T трафик. Это гиг по 300 в сутки. https://www.hetzner.com/storage/storage-share?country=ua За ту же стоимость немного другая услуга. Снепшоты можно делать. https://www.hetzner.com/storage/storage-box?country=ua

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

Я покушал, потянуло на творчество. Кстати, подскажите, как отключить этот слишком умный редактор на локале? 1. Во первых, никакие маки не маршрутизируются. Никто не будет роутить префиксы, длинее /64. Ну, разве вы у себя локально будете расбрасывать. Во вторых, там содержатся поля маков только в некоторых случаях (!!!), только при определенных ситуациях (!!!). Более того, адрес, в котором зашит мак, является приватным, и "нвружу" не выходит. Для ходьбы наружу автоматически генерируется случайны адрес без сигнатуры мака, которым клиент и ходит в мир. Казалось бы, сложно.... Но плата за это - абсолютно автоматическая настройка подключение устройства сети. На устройстве не нужны никакие дополнительные программы, разные dhcp-клиенты/шмулетны и т.д. Все делается на уровне стека, и подавляющему большинству людей вообще не нужно. Вот кто сейчас из "прохожих" сможет объяснить, что такое tcp-окно, или, хотя бы, тот же MAC? Тут тоже самое. 2. По поводу 128 бит. Во первых, я даже не знаю, остались ли еще в природе 32-битные процессоры (ну, кроме, примитивных контроллеров). А для обработки 32-битного числа (ipv4) хранящегося с другими в 128-биной ячейке памяти, надо распковывать в 64- или 128-битный регистр... С другой стороны, сейчас некоторые программисты хераячат такой софт, который вообще не понятно, чем занимается. Пример у россиянских коллег, вся работа которых свелась к одному попо-болю - есть пропуск, или нет - просто с ума сходят от того, что их сраный софт не может в разумные рамки обработать 1.5M целых 32-битных чисел... Или другой вопрос - биллинг. Простая целочисленная задача, оперирующая 1-10-100 тыс объектов. Я не знаю, как надо биллинг накалапоцать, что бы он превращался в сталелитейную установку, выполняя примитивные операции, в максимальном случае с целочисленной арифметикой. 3. Мы уходили от NAT для клиента. И мы усшли от него - клиент имеет нормальный реальный адрес. NAT64 - это нат на те сервисы интернета (сайты, например), владельцы которых так и не додятлили до того, что бы поставить второй стек и ipv6. Вот мы их и натим. И это временное и совсем неправильное решение на данный момент. Но в один прекрасный момент эти наты отключатся, и отдельные дяди останутся без посетителей. Добро пожаловать в мир v4 Это как поставили компьютер, но технология осталась бумажной. На данный момент, пока ipv6 развернуто еще не везде, игроки рынка до конца не определились, видимо, такая мера необходима, как временное переходное решение. Я думаю, что постепенно от этого будут отказываться. Я по этому поводу писал, если не ошибаюсь, в этом топике уже. Это так, и это один из тормозов нормального внедрения v6. Но первая причина - лень и нежелание "что-то почитать" толстопузыми дядями, считающими себя специалистами.:) Нормально ppp прокачивает оба протокола. На линк, кстати, не надо выделять реальные адреса. Он нормально работает по ll addr. По правилам хорошего тона, клиенту желательно отдавать префикс /56. Ну, или хотя бы, /60. Ибо в ipv6 как-то не принято бриджить, как минимум wire and wifi interfaces.

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

Что-то я как-то бестолково пишу. Сходил, покушал. Решил дополнить. Представьте ситуацию. Вы покупаете ether-какрту. А продавец говорит, что, мол, там есть MAC-адрес, за него надо заплатить. И более того, надо ежегодно оплачивать его использование... Странно, что никто еще не додумался торговать MAC-ами. Потому, что MACи - это абсолютно технологический компонет, вокруг которого нет никакого фетиша. Вот если вы производите сетевое оборудование, то тут уже другой вопрос - вам необходимо получить свой mac-префикс. Или прикинуться китайцем Введение ipv6 так же подкинуло идею отказаться от фетиша ip-адреса от слова "совсем". Превратить его в чисто технологический компонент. Адресное пространство ipv6 позволяет так к ним относиться. Следующее, современный интернет уже давно разделил суть узлов сети, определив их как производителем услуг и потребителем. От этого зависит разная политика предоставления ip адресов. Если вы потребитель, то совершенно не важно, какой именно у вас адрес в каждый конкретный момент. Учитывая то, что этот адрес генерит само устройство случайным образом в рамках префикса, если по хорошему. При этом, для потребителя совершенно не важно, как и как быстро меняется префикс. Адреса перестают быть фетишем, их уже не надо настраивать вручную, и тем более, запоминать. Фетишем становятся домены с dns, в том числе, динамические. Другое дело производители услуг. Тут уже стоит закреплять адреса за серверами, которые предоставляют услуги. При этом, в эпоху cdn, значимость этого падает. Что делать при нескольких линках. Если речь идет о серверной стороне - нет проблем - прописываем в dns 2 и более адресов по количеству линков, как это делается сейчас для ipv4. Если речь идет о потребителе интернет-услуг - то вариантов много - от прозрачной трансляции до выдачи нескольких ip на каждого потребителя. Если вы ставите 2 eth-карты в компьютер - вас не смущает, что ваш узел имеет два разных mac-адреса. Точно так же не должно смущать несоклько префиксов, если вы создаете multihomed систему. Я так понимаю, что в ipv6 стараются построить сеть без всех этих безумных и ненужных обменов километровыми таблицами рутинга. Если вы покупаете сетевое оборудование - оно идет со своими MAC-адресами. А если вы покупаете uplink - то он должен быть "укомплектован" достаточным количеством ipv6 адресов. Ну вот как-то так. Что делать сейчас небольшому провайдеру. Если у одного взять /48, а другие аплинки возьмутся их анонсить - так и делать. На какое-то время хватит.

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

1. Первый абсурд - это попытка торговать префиксами так же, как торговали сетками в ipv4. Этот товар не стоит столько. И не должен столько стоить. Пока будут пытаться продавать - ipv6 будет тормозиться. 2. Речь не идет о NAT'е. Речь идет о трансляции 1в1 Никаких таблиц коннектов держать не надо, адресов достаточно. Не нравится - есть другие варианты. 3. И речь идет о совершенно другой идеологии, при которой сетки не растаскиваются в рамках PI, а держаться "кучками". Никто не будт таскать/48 по разным роутингам. Поэтому, когда IRы "проникнутся" новыми идеями, тогда дело и пойдет. К этому надо привыкать. Как я писал, у ipv6 немного другая утилитарная нагрузка. https://labs.ripe.net/Members/stephen_strowes/visibility-of-prefix-lengths-in-ipv4-and-ipv6 Цитата: Типа, був час та натхнення, что бы устроить старый добрый бардак.

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

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". И что бы не вставать два раза: Называется "развивать победное наступление" Дружище, мне, честно говоря, наплевать на проблемы "производственников". Мне не интересно заниматься скучной работой. поэтому я продал свой провайдер много лет назад после 15 лет провайдерства. Однако... Что-то я запутался - надо или не надо. Вообще, для авторизации не обязательно использовать логины и пароли. Для авторизации есть много других способов, которые не требуют введения пароля - от SMS и smartcard (payment-id) и до сканирования qr-code. И речь, будем честным, не о "дополнительной" авторизации, а о входе в свой кабинет клиента, не более того. Тут есть одна грустная история. Если вы используете костыль, то он, как тот же скрипт, о котором вы тут мне сообщили "новость", просто не хранит лизы и не хранит MAC-и. Поэтому тут можно только пожелать успехов в ручном труде персонала. Я даже не буду повторять фразу - вам больше нечем заняться? Я пытаюсь говорить о 21-м веке, а не о "нам и так не плохо".

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

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

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

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

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

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

(Анекдот) У логопеда: - Доктор, я плохо выговариваю букву Ч? - Ну как же, дружище! Совсем даже не плохо выговариваете! - Ну не чавчем.:) И так, схема такая. В одном месте оказываются человек и розетка (та, которую когда-то поставил монтажник). Просто не забываем, что в цивилизованном случае в квартире у человека электрические и ethernet розетки изначально давно установлены и куда надо подключены. Человек втыкает что-то интернет-кушающее в розетку. 1. Этот этап пропускам в описании, так-как для Украины не актуально (интеграторы последней мили в стране не прижились). 2. "Если вы у нас первый раз - зарегистрируйтесь, если вы наш клиент - залогиньтесь". Человек (в мире диджитализации) прикладывает свою id-card, (а в отсталом мире) вводит свое имя, телефон, адрес. Монтажник тут не при чем, ибо он был тут последний раз 3 года назад, когда строили район.:) 3. Если человек уже клиент, просто логинится, прикладывая какое-нибудь диджитализирующее устровйтсво к диждитализирующему идентификатору... Ну, например, сканирует qr-code. И это только в случае замены оборудования или других проблем. Иначе клиент никуда не заходит и ничего не вводит. 3. Если клиент новый - он заходит в свой профайл, выбирает услугу(-и), произовдит оплату в "ван клик" одним из 1072 доступных способов, и забывает об остальных отношениях своих с провайдером. Факт оплаты в цивилизованной стране является фактом подписывания договора. Вопрос адреса. Если дядя покупает в интернет магазине энциклопедию (или надувную тётку), он вводит там свой адрес для доставки товара. Тут то же самое - введите свой адрес, без которого мы не сможет пофиксить неисправности, если таковые возникнут. Не введет клиент свой адрес, работает все, платит - ну и слава богу, деньги поступают, мороки нет. Вот такая простенькая схема. И да, такая схема не нова. Она была запущена (сейчас посмотрю...) в мае 2005 года. С тех пор я слышал огромное количество "аргументов" со стороны украинских провайдеров, почему они это делать не хотят, им это не выгодно, это не правильно... Ну то дело такое.

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