Bug 27780 - IPv6 support
Summary: IPv6 support
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: etcnet (show other bugs)
Version: unstable
Hardware: all Linux
: P3 enhancement
Assignee: Mikhail Efremov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 27685
  Show dependency tree
 
Reported: 2012-09-28 19:06 MSK by Mikhail Efremov
Modified: 2012-11-08 18:44 MSK (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Efremov 2012-09-28 19:06:45 MSK
В 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.
Comment 1 Sergey Bolshakov 2012-09-28 23:15:41 MSK
1. dhcpv6 переоценён, честно говоря, dhcpcd умеет ловить RA, RDNSS и DNSSL,
   а большего не особенно и нужно. Впрочем, появится dhclient, посмотрим.
2. да, что-то такое следовало бы сделать. впрочем, все уже давно приучены
   к echo ipv6 >> /etc/modules
3. see 1, мне хватает
4. ох, давайте их ещё оба на одном интерфейсе запускать. что-то мне
   перспектива заполучить ещё и dhclient разонравилась.
Comment 2 Mikhail Efremov 2012-09-29 14:28:48 MSK
(В ответ на комментарий №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. Но прежде чем что-то делать, нужно хорошенько подумать, чтобы не пришлось переделывать.
Comment 3 Denis Ovsienko 2012-09-30 23:15:40 MSK
Миша меня сюда вписал, наверное, чтобы я дал комментарий. Сейчас мне видится, что RA является вполне самостоятельным BOOTPROTO безотносительно возможности его комбинации с DHCPv6 (сам не пробовал) и безотносительно того, какой BOOTPROTO является умолчательным. Польза этого в том, чтобы по содержимому конфига интерфейса была возможность понять, что произойдёт при его обработке, а что _не_ произойдёт. В своё время, правда, я RA упустил из вида и теперешний static фактически может означать "static+RA". Надеюсь, эта информация поможет.
Comment 4 Mikhail Efremov 2012-10-01 18:08:21 MSK
Сейчас работа 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 даже если эти файлы есть. Ну и да, сразу по конфигу будет понятнее как конфигурируется интерфейс.
Comment 5 Michael Shigorin 2012-10-02 11:18:42 MSK
(In reply to comment #3)
> Миша меня сюда вписал, наверное, чтобы я дал комментарий.
Именно; спасибо.
Comment 6 Mikhail Efremov 2012-10-17 20:52:59 MSK
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 приносит больше проблем, чем пользы.
Comment 7 Denis Ovsienko 2012-10-17 22:16:10 MSK
--- 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 тоже.
Comment 8 Mikhail Efremov 2012-10-17 23:14:46 MSK
(В ответ на комментарий №7)
> -DONT_FLASH=yes
> +DONT_FLUSH=yes

Спасибо, не заметил.

> Я бегло просмотрел, там есть ряд и других изменений. Нужно заметить, что 802.1X
> работает и для обычного Ethernet тоже.

Об этом есть в https://bugzilla.altlinux.org/27797.
Comment 9 Sergey Bolshakov 2012-10-18 18:24:22 MSK
относительно RA:
сейчас static действительно означает static+RA, и я этим чрезвычайно доволен.
полагаю также, что выделенный BOOTPROTO=ra с семантикой 'не делаем ничего,
даже если существуют ipv[46]address и что там ещё' скорее вреден, незачем
умножать сущности без нужды.
Comment 10 Sergey Bolshakov 2012-10-18 18:27:34 MSK
относительно options-ipv[46]:
можно озвучить список опций, которые предполагается иметь разными в этих файлах ?
Comment 11 Mikhail Efremov 2012-10-18 21:26:02 MSK
> полагаю также, что выделенный BOOTPROTO=ra с семантикой 'не делаем ничего,
> даже если существуют ipv[46]address и что там ещё' скорее вреден, незачем
> умножать сущности без нужды.

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

> относительно options-ipv[46]:
> можно озвучить список опций, которые предполагается иметь разными в этих файлах
> ?

Любые, которые используются в config-ipv[46], т.е. те, которые используются для конфигурации именно IP. В частности можно задать BOOTPROTO=static в options-ipv6 и BOOTPROTO=dhcp в options-ipv4, например.
Comment 12 Sergey Bolshakov 2012-10-18 23:54:04 MSK
> Это скорее для ясности. Чтобы глядя в конфиг можно было сразу понять, что это
> интерфейс конфигурируется не статически, а через RA. RA - это, все-таки, совсем
> не статик, это ровно наоборот.

Не, нету в этом ясности.
При таком подходе ситуацию 'я хочу иметь заполненные ipv[46]address, но не хочу их использовать' можно раcширять на какие угодно другие файлы.
Вообще, чем будет меньше этого птичьего языка в OPTIONS c мутной семантикой,
тем лучше.
К тому же RA достаточно static -- при неизменном префиксе и маке адрес будет тем же.

> Любые, которые используются в config-ipv[46] ...
Спрошу иначе: какие, по твоему мнению, опции *вынуждают* нас завести
options-ipv[46] (ну, помимо BOOTPROTO)
Comment 13 Denis Ovsienko 2012-10-18 23:57:42 MSK
Чтобы отличить неплохое от оптимального, мне требуется ясный ум и до нескольких месяцев времени.
Comment 14 Mikhail Efremov 2012-10-19 16:32:22 MSK
(В ответ на комментарий №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] (глобально или для конкретного интерфейса, это уж на усмотрение администратора).
Comment 15 Dmitry V. Levin 2012-10-25 20:15:43 MSK
(In reply to comment #12)
> Не, нету в этом ясности.

Короче говоря, давайте уже реализуем нормальную поддержку IPv6.

Сергей, если тебе не нравится все, что предлагает Михаил, то сделай тогда быстренько поддержку IPv6 сам. :)
Comment 16 Sergey Bolshakov 2012-10-25 23:27:42 MSK
во-первых, IPv6 support, который как бы предлагается к добавлению -- есть уже давно, годы. Чего нет, так это поддержки DHCPv6, что собственно здесь и обсуждается,
и кстати говоря останется в этом положении, пока в сизифе наконец не появится
свежий dhclient -- чего ждём-то ?
что мне действительно не нравится в предлагаемой схеме, так это разделение
options, которое обосновывается необходимостью во-первых, разных дефолтов
DONT_FLUSH для v4 vs v6 (я не вижу в этом совершенно никакой нужды, критичные
для v6 link-local адреса и без того не чистятся, остальное неважно), и во-вторых, желанием иметь несколько одновременных BOOTPROTO на интерфейсе,
что вообще-то требует хорошего обоснования.
cуммируя: я жду
1) dhclient в сизифе
2) патч, добавляющий его поддержку, но без этих 'а давайте их два запускать',
разделения options и этих options.d в самых неожиданных местах -- минимальный,
насколько это вообще возможно, патч -- ну, или сам нарисую после 1).
Comment 17 Mikhail Efremov 2012-10-26 17:03:54 MSK
(В ответ на комментарий №16)
> и кстати говоря останется в этом положении, пока в сизифе наконец не появится
> свежий dhclient -- чего ждём-то ?

На следующей неделе будет.

> что мне действительно не нравится в предлагаемой схеме, так это разделение
> options, которое обосновывается необходимостью во-первых, 
> разных дефолтов DONT_FLUSH для v4 vs v6 (я не вижу в этом совершенно никакой нужды, критичные
> для v6 link-local адреса и без того не чистятся, остальное неважно), и

Во-первых, без него нужен хак для lo, во-вторых зачем сносить адреса, полученные через RA? Понятно, что скорее всего они опять вернутся, но зачем вообще их сносить? Время их жизни и так регулируется. К тому же IPv6 адреса убираются при опускании интерфейса, в отличие от IPv4.

> во-вторых, желанием иметь несколько одновременных BOOTPROTO на интерфейсе,
> что вообще-то требует хорошего обоснования.

По-моему, требует обоснования почему этого делать нельзя. Одновременная конфигурация IPv4 и IPv6 на одном интерфейсе - что, не допустима?
Comment 18 Mikhail Efremov 2012-10-30 22:18:35 MSK
> я жду
> 1) dhclient в сизифе
> сам нарисую после 1).

Рабочий dhclient в Сизифе (4.2.4.P2-alt2).
Comment 19 Sergey Bolshakov 2012-11-08 00:16:49 MSK
(В ответ на комментарий №18)
> > я жду
> > 1) dhclient в сизифе
> > сам нарисую после 1).
> 
> Рабочий dhclient в Сизифе (4.2.4.P2-alt2).

как оказалось, не вполне рабочий.
при использовании -6 опция -timeout похоже игнорируется, так что
если поблизости нет DHCPv6-сервера, ifup будет вечным.
Comment 20 Mikhail Efremov 2012-11-08 16:31:26 MSK
> при использовании -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 если нет.
Comment 21 Mikhail Efremov 2012-11-08 17:18:10 MSK
> Видимо в случае DHCPv6 нужно просто добавлять -1 если установлен DHCP_TIMEOUT и
> -nw если нет.

Хотя нет, -nw не надо. Отсутствие DHCP_TIMEOUT означает просто значение по умолчанию, а не бесконечное ожидание, конечно.
Comment 22 Repository Robot 2012-11-08 18:44:07 MSK
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)