> КАК ИМЕННО получает? Желательно описать процесс отдельно для DHCP-винды, DHCP-Linux, DHCP-MacOS, Какой в ж... dhcp? У ipv6 автоконфигурация без всяких dhcp есть, для начала.
> PPPoE, PPTP, L2TP,
А это вообще маздай. Как раз наконец провы купят себе нормальное оборудование вместо горбатых пионернетовских останков. Делать коммерческую сетку из офисно-домашних свичей - ну знаете, как-то не совсем правильно. Нормальные провы уже давно выводы сделали. А с нормальными свичами можно и более-менее обычный роутинг использовать. Как раз железки у хомяков разгрузятся в несколько раз. А то железку способную осилить pptp на 50 мбит в 2 стороны - это еще суметь надо. Хрень за 1300 рублей точно сольется на этом начинании. А вот чисто роутинг больших пакетов - даже оно осилит.
>> А какие проблемы выдавать подсеть помельче?
> Проблема в телепатическом выделении мыльницей подсети помельче. Либо юзеру всё равно придётся
> руками писать подсети, либо одно из двух.
Ну например если тебе дали /64, выдавать /32 всем кто за тобой. Только не надо лечить что 2^32 подсетей с 2^32 девайсов в каждой не хватит домашнему юзеру, ага. Он там может хоть всех бацилл в доме айпишником снабдить.
> каждого юзера вместо одного мака будем видеть десяток - сетям будет
> плохеть.
Ну если у вас оборудование которому плохеет, потребуйте чтобы подключение делалось через роутер. Тогда вы не будете видеть мак-адреса чего либо кроме роутера.
> А управлять 100500 хомячков как предполагаете? Статика годна только для пионернетов,
Обычная механика ipv6 + тушить порты через ремотное управление свичом тем кто принципиально не платит. Так ща куча провов с v4 делает, иногда взаимоизолируя хомячков через вланы для уменьшения хаков. И вот что-что а удаленное тушение порта биллингом - ну никак не обойдешь. Тогда как все эти горбыли обычно оставляют те или иные лазейки шибко вумным неплательщикам, заваливаются напрочь при любом отказе серверов и какой там еще геморрой. Не говоря о том что для их терминации нужен обуенный парк серверов.
> где юзеров не много. В больших сетях нужна статистика, нужно динамическое управление
> полосой пропускания, причём желательно быстрое, без вмешательства в конфиги железок.
А какая биллингу разница - параметры на серваке покрутить или параметры на железке? Примерно однохренственно получается. Тем более что скорость по интранету мало кого волнует, а скорость интернета можно нарезать и где-то ближе к граничным узлам уже.
> Есть концентраторы доступа, которые IPoE поддерживают, но с IPv6 у них всё
> так же туго.
Да просто поразвели извращений всяких а теперь еще и пытаются доказать что это не они виноваты в том что на костылях бегать неудобно.
>> А неплательщиков надежнее всего глушить, извиняюсь, просто отключением порта на свиче.
> Отключить разом несколько десятков тысяч портов в момент изменения состояния биллинга -
> это задача, конечно же, очень простая.
Эта задача - подсмотрена, извините, у реальных провайдеров, которые реально так делают - биллинг видя что бабла нет просто идет и кладет порт через интерфейс управления свича. Так реально делает ряд провов. Вполне цивильно работает, всем все понятно и всех вроде устраивает. И для юзера вполне цивильно, и для прова, и работает как обычный такой роутинг для всего оборудования. Очень мило и позитивно получается и все довольны. И нагрузка на малосильные хомячьи роутеры минимальная, в отличие от левых оверлейных протоколов.
До провов кстати доперло что хорошо, когда периоды тарификации абонентов размазаны по времени и поэтому не надо как раз нагибать тысячи абонентов синхронно. Сначала именно была фиксированная дата оплаты. И саппорты дружно вешались в день оплаты, когда тысячи хомяков тотально перегружали колцентры, т.к. половина конечно же забудет про дату оплаты. Сейчас до всех вменяемых провов уже дошло что это не умно и у каждого хомяка оплата - когда он деньги на счет внес, ну и когда внесенное закончилось, соответственно. Поэтому никаких десятков тысяч портов за раз. Никаких тысяч пострадавших в сутки. Все равномерно раскидано, как раз потому что так лучше всем. И биллингу, и хомякам, и прову.
> Особенно с учётом того, что ряд свитчей по причине аварий в этот
> момент может отсутствовать.
Ну да, конечно, а повторить попытку - религия не позволит, вероятно. К тому же если свич отсутствует - юзер и так уже выключен :). Насколько справедливо его вообще @#нуть биллингом при этом - вопрос вообще интересный. Ему по идее пересчет должны бы сделать за отвал сети, не?
> управления не иметь...). И - ваше счастье, если от первого момента
> до второго ни один свитч не упадёт.
Я уж не знаю как вы нашли проблемы там где их нет, но я знаю нескольких реально существующих провов (довольно крупных) которые делают так как я описал. Какие-то отличия у них могут быть в деталях, но с точки зрения подключающегося это все-равно остается наиболее прямой вариант. С минимальной нагрузкой на хомяковый роутер. И я не вижу почему там не должен взлететь v6.
> В случае PPPoE/PPTP/L2TP это делается "на счёт раз", без особого напряга и
> запинок - тупой записью в базу RADIUS, и выдачей CoA для
> "живых" сессий на считанное число априори живых концентраторов.
Ага, а при отвале концентраторов или радиуса у таких будаков вообще такой ад и содом начинается что саппорт готов застрелиться. Вся сеть дружно идет звонить в колцентр, он немедленно становится перегружен и время ожидания в очереди немедленно взлетает вплоть до трех часов слушания музыки (что вставляет при звонке с мобильника).
> А вот управление портами годится, повторюсь, только для пионернетов с считанными десятками свитчей.
Вообще-то именно так делают несколько очень крупных провов, с десятками-сотнями тысяч абонентов. У них получается. Ну а я с удовольствием ими пользуюсь, соответственно. Потому что в гробу я видал кайф 50 мбит pptp разгребать или там куковать совсем без интернета если концентраторы дадут дуба. Да и двойной интерфейс к прову "сначала WAN-DHCP, потом впн поверх" - это дико нестандартное местечковое извращение. В остальном мире так почти не делают вообще.
> Лазейку в PPPoE? Ну-ну...
Сильно зависит от организации сети. Если мне дали айпи на WAN по DHCP и там чего-то доступно - почему бы собственно и нет? В то время как против положенного порта вообще ничего и не придумаешь - только бабло в кассу...
