В etcnet сейчас есть поддержка только static для IPv6. Для полноценной поддержки IPv6 нужно решить следующие вопросы: 1. Поддержка DHCPv6. Т.к. dhcpcd не умеет DHCPv6, придется использовать dhclient от ISC (его пока нет, но скоро появится в Сизифе). Поддержку dhclient надо переделывать, тех опций, на которые рассчитывает etcnet, у апстримного dhclient нет (и, похоже, никогда не было). В Fedora есть патч, добавляющий разные полезные опции, видимо его надо приложить и считать, что etcnet поддерживает только dhclient с этим патчем (иначе нельзя будет обеспечить поддержку DHCP_TIMEOUT, например). 2. Etcnet пытается грузить модуль ipv6 если включена соответствующая опция, но это уже поздно, т.к. модуль уже должен быть загружен на момент использования /etc/net/sysctl.conf если там прописаны IPv6-специфичные опции. Т.е. делать это надо в инит скрипте, плюс нужна управляющая этим опция в /etc/sysconfig/network. Впрочем, т.к. модуль у нас больше не заблэклистен по умолчанию, то может это все и неактуально. 3. Нужно ли вводить отдельное состояние в BOOTPROTO для RA? Скорее всего нет, т.к. в этом случае etcnet скорее всего не должен делать ничего вообще. Должно сгодиться static без конфигурации. 4. Возможно некоторые опции надо разделить на IPv4-only и IPv6-only (например DONT_FLUSH). Также может быть полезна возможность использовать разные dhcp-клиенты для DHCPv4 и DHCPv6.
1. dhcpv6 переоценён, честно говоря, dhcpcd умеет ловить RA, RDNSS и DNSSL, а большего не особенно и нужно. Впрочем, появится dhclient, посмотрим. 2. да, что-то такое следовало бы сделать. впрочем, все уже давно приучены к echo ipv6 >> /etc/modules 3. see 1, мне хватает 4. ох, давайте их ещё оба на одном интерфейсе запускать. что-то мне перспектива заполучить ещё и dhclient разонравилась.
(В ответ на комментарий №1) > 1. dhcpv6 переоценён, честно говоря, dhcpcd умеет ловить RA, RDNSS и DNSSL, > а большего не особенно и нужно. Впрочем, появится dhclient, посмотрим. DHCPv6 - это не альтернатива RA, это скорее дополнение к нему. RA достаточно только для простых случаев. Если нужно раздать конкретные адреса конкретным клиентам или передать дополнительную конфигурацию (hostname, адрес NTP-сервера, etc), то нужно использовать DHCPv6. Есть еще prefix delegation, но это отдельный вопрос. Кстати, для RA dhcpcd вообще говоря не нужен: RA умеет ядро, а для RDNSS/DNSSL есть rdnssd. > 4. ох, давайте их ещё оба на одном интерфейсе запускать. что-то мне > перспектива заполучить ещё и dhclient разонравилась. Разумеется, такая возможность должна быть. Более того, хорошо бы иметь возможность задать смешанную конфигурацию: dhcp для IPv4 и static для IPv6. Почему нет? IPv4 и IPv6 конфигурации интерфейса никак между собой не связаны. Я все это вообще к тому, вполне готов взять на себя реализацию всего этого в etcnet. Но прежде чем что-то делать, нужно хорошенько подумать, чтобы не пришлось переделывать.
Миша меня сюда вписал, наверное, чтобы я дал комментарий. Сейчас мне видится, что RA является вполне самостоятельным BOOTPROTO безотносительно возможности его комбинации с DHCPv6 (сам не пробовал) и безотносительно того, какой BOOTPROTO является умолчательным. Польза этого в том, чтобы по содержимому конфига интерфейса была возможность понять, что произойдёт при его обработке, а что _не_ произойдёт. В своё время, правда, я RA упустил из вида и теперешний static фактически может означать "static+RA". Надеюсь, эта информация поможет.
Сейчас работа DHCPv6 без RA не предполагается вообще. Хотя в будущем это может измениться (см. http://www.isc.org/community/blog/201111/routing-configuration-over-dhcpv6, http://datatracker.ietf.org/doc/draft-ietf-mif-dhcpv6-route-option/). Отдельный же BOOTPROTO для RA-only действительно нужен, пожалуй. Чтобы при указании такого BOOTPROTO интерфейс только поднимался и не применялась конфигурация из ipv6address/ipv6route даже если эти файлы есть. Ну и да, сразу по конфигу будет понятнее как конфигурируется интерфейс.
(In reply to comment #3) > Миша меня сюда вписал, наверное, чтобы я дал комментарий. Именно; спасибо.
http://git.altlinux.org/people/sem/packages/etcnet.git?p=etcnet.git;a=shortlog;h=refs/heads/ipv6 Вкратце: - Доработана поддержка dhclient. - Добавлено BOOTPROTO=ra для RA-only. - Поддержка DHCPv6, пока только для dhclient. Кстати, в dhcpcd появилась зачаточная поддержка DHCPv6. Надеюсь скоро ее допилят и можно будет использовать dhcpcd для DHCPv6. Впрочем, поддержка dhclient в etcnet в любом случае не помешает. - Добавлена возможность записывать опции, специфичные для IP-версии в отдельные конфиги options-ipv4 и options-ipv6. Это позволит не добавлять IPv6-версии переменных и делать раздельную конфигурацию интерфейса для IPv4 и IPv6. - Для IPv6 выставлено DONT_FLUSH=yes по умолчанию. Для IPv6 flush приносит больше проблем, чем пользы.
--- a/etc/net/ifaces/default/options-ipv6 +++ b/etc/net/ifaces/default/options-ipv6 @@ -1,3 +1,3 @@ # IPv6 addresses shouldn't be flushed normally -DONT_FLASH=yes +DONT_FLUSH=yes DHCP_CLIENT=/sbin/dhclient Я бегло просмотрел, там есть ряд и других изменений. Нужно заметить, что 802.1X работает и для обычного Ethernet тоже.
(В ответ на комментарий №7) > -DONT_FLASH=yes > +DONT_FLUSH=yes Спасибо, не заметил. > Я бегло просмотрел, там есть ряд и других изменений. Нужно заметить, что 802.1X > работает и для обычного Ethernet тоже. Об этом есть в https://bugzilla.altlinux.org/27797.
относительно RA: сейчас static действительно означает static+RA, и я этим чрезвычайно доволен. полагаю также, что выделенный BOOTPROTO=ra с семантикой 'не делаем ничего, даже если существуют ipv[46]address и что там ещё' скорее вреден, незачем умножать сущности без нужды.
относительно options-ipv[46]: можно озвучить список опций, которые предполагается иметь разными в этих файлах ?
> полагаю также, что выделенный BOOTPROTO=ra с семантикой 'не делаем ничего, > даже если существуют ipv[46]address и что там ещё' скорее вреден, незачем > умножать сущности без нужды. Это скорее для ясности. Чтобы глядя в конфиг можно было сразу понять, что это интерфейс конфигурируется не статически, а через RA. RA - это, все-таки, совсем не статик, это ровно наоборот. > относительно options-ipv[46]: > можно озвучить список опций, которые предполагается иметь разными в этих файлах > ? Любые, которые используются в config-ipv[46], т.е. те, которые используются для конфигурации именно IP. В частности можно задать BOOTPROTO=static в options-ipv6 и BOOTPROTO=dhcp в options-ipv4, например.
> Это скорее для ясности. Чтобы глядя в конфиг можно было сразу понять, что это > интерфейс конфигурируется не статически, а через RA. RA - это, все-таки, совсем > не статик, это ровно наоборот. Не, нету в этом ясности. При таком подходе ситуацию 'я хочу иметь заполненные ipv[46]address, но не хочу их использовать' можно раcширять на какие угодно другие файлы. Вообще, чем будет меньше этого птичьего языка в OPTIONS c мутной семантикой, тем лучше. К тому же RA достаточно static -- при неизменном префиксе и маке адрес будет тем же. > Любые, которые используются в config-ipv[46] ... Спрошу иначе: какие, по твоему мнению, опции *вынуждают* нас завести options-ipv[46] (ну, помимо BOOTPROTO)
Чтобы отличить неплохое от оптимального, мне требуется ясный ум и до нескольких месяцев времени.
(В ответ на комментарий №12) > > Это скорее для ясности. Чтобы глядя в конфиг можно было сразу понять, что это > > интерфейс конфигурируется не статически, а через RA. RA - это, все-таки, совсем > > не статик, это ровно наоборот. > > Не, нету в этом ясности. > При таком подходе ситуацию 'я хочу иметь заполненные ipv[46]address, но не хочу > их использовать' можно раcширять на какие угодно другие файлы. Я и не утверждаю, что заполнить эти файлы и не использовать - нормально. > Вообще, чем будет меньше этого птичьего языка в OPTIONS c мутной семантикой, > тем лучше. Я согласен, что BOOTPROTO=ra довольно искусственен и, фактически, не отличается от static без конфигурации. Пытаться же поменять семантику static со static+RA на static-only я, разумеется, не предлагаю, не вижу в этом никакого смысла. Единственный аргумент в пользу отдельного BOOTPROTO - ясность конфигурации, т.к., повторяю, RA - это не static. Впрочем, в случае BOOTPROTO=ra могут появиться и другие действия, например там потенциально можно запускать что-то, что будет обрабатывать RDNSS/DNSSL: инструментов для этого несколько, как минимум это умеют dhcpcd и rdnssd. Но я пока не уверен, что это действительно необходимо. > К тому же RA достаточно static -- при неизменном префиксе и маке адрес будет > тем же. С таким же успехом можно утверждать, что при неизменной конфигурации DHCP-сервера и привязке адресов к маку - это тоже static. RA - это как раз очень даже dynamic, причем часто с ограниченным lifetime. > > Любые, которые используются в config-ipv[46] ... > Спрошу иначе: какие, по твоему мнению, опции *вынуждают* нас завести > options-ipv[46] (ну, помимо BOOTPROTO) DONT_FLUSH и DHCP_CLIENT. Альтернатива введению отдельных файлов конфигурации - заведение отдельных опций для IPv6. Это мне кажется гораздо худшим вариантом. В таком же виде использовать options-ipv[46] для интерфейса на самом деле нужно далеко не всегда. Это только если действительно нужно задать разную конфигурацию IPv4 и IPv6. Если же нужно просто перейти с DHCPv4 на DHCPv6, например, то достаточно только задать нужные CONFIG_IPV[46] (глобально или для конкретного интерфейса, это уж на усмотрение администратора).
(In reply to comment #12) > Не, нету в этом ясности. Короче говоря, давайте уже реализуем нормальную поддержку IPv6. Сергей, если тебе не нравится все, что предлагает Михаил, то сделай тогда быстренько поддержку IPv6 сам. :)
во-первых, IPv6 support, который как бы предлагается к добавлению -- есть уже давно, годы. Чего нет, так это поддержки DHCPv6, что собственно здесь и обсуждается, и кстати говоря останется в этом положении, пока в сизифе наконец не появится свежий dhclient -- чего ждём-то ? что мне действительно не нравится в предлагаемой схеме, так это разделение options, которое обосновывается необходимостью во-первых, разных дефолтов DONT_FLUSH для v4 vs v6 (я не вижу в этом совершенно никакой нужды, критичные для v6 link-local адреса и без того не чистятся, остальное неважно), и во-вторых, желанием иметь несколько одновременных BOOTPROTO на интерфейсе, что вообще-то требует хорошего обоснования. cуммируя: я жду 1) dhclient в сизифе 2) патч, добавляющий его поддержку, но без этих 'а давайте их два запускать', разделения options и этих options.d в самых неожиданных местах -- минимальный, насколько это вообще возможно, патч -- ну, или сам нарисую после 1).
(В ответ на комментарий №16) > и кстати говоря останется в этом положении, пока в сизифе наконец не появится > свежий dhclient -- чего ждём-то ? На следующей неделе будет. > что мне действительно не нравится в предлагаемой схеме, так это разделение > options, которое обосновывается необходимостью во-первых, > разных дефолтов DONT_FLUSH для v4 vs v6 (я не вижу в этом совершенно никакой нужды, критичные > для v6 link-local адреса и без того не чистятся, остальное неважно), и Во-первых, без него нужен хак для lo, во-вторых зачем сносить адреса, полученные через RA? Понятно, что скорее всего они опять вернутся, но зачем вообще их сносить? Время их жизни и так регулируется. К тому же IPv6 адреса убираются при опускании интерфейса, в отличие от IPv4. > во-вторых, желанием иметь несколько одновременных BOOTPROTO на интерфейсе, > что вообще-то требует хорошего обоснования. По-моему, требует обоснования почему этого делать нельзя. Одновременная конфигурация IPv4 и IPv6 на одном интерфейсе - что, не допустима?
> я жду > 1) dhclient в сизифе > сам нарисую после 1). Рабочий dhclient в Сизифе (4.2.4.P2-alt2).
(В ответ на комментарий №18) > > я жду > > 1) dhclient в сизифе > > сам нарисую после 1). > > Рабочий dhclient в Сизифе (4.2.4.P2-alt2). как оказалось, не вполне рабочий. при использовании -6 опция -timeout похоже игнорируется, так что если поблизости нет DHCPv6-сервера, ifup будет вечным.
> при использовании -6 опция -timeout похоже игнорируется, так что > если поблизости нет DHCPv6-сервера, ifup будет вечным. Оказывается это не бага, это фича. Таймаут будет использоваться только в случае добавления опции -1 (см. dhclient(8)). Это означает выставление MRD=timeout и после его истечения dhclient завершает работу. Это поведение в принципе соответствует RFC3315: A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. Видимо в случае DHCPv6 нужно просто добавлять -1 если установлен DHCP_TIMEOUT и -nw если нет.
> Видимо в случае DHCPv6 нужно просто добавлять -1 если установлен DHCP_TIMEOUT и > -nw если нет. Хотя нет, -nw не надо. Отсутствие DHCP_TIMEOUT означает просто значение по умолчанию, а не бесконечное ожидание, конечно.
etcnet-0.9.10-alt8 -> sisyphus: * Thu Nov 08 2012 Sergey Bolshakov <sbolshakov@altlinux> 0.9.10-alt8 - service network should not start on 2nd runevel (closes: #25700) - DHCPv6 support added (closes: #27780)
