<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>Mikrotik.moscow [тема: Проблема с DHCPv6 клиентом]</title>
		<link>http://mikrotik.moscow</link>
		<description>Новое в теме Проблема с DHCPv6 клиентом форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow]</description>
		<language>ru</language>
		<docs>http://backend.userland.com/rss2</docs>
		<pubDate>Wed, 12 Aug 2026 22:02:31 -0400</pubDate>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388836">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Звучит хорошо. Надеюсь, я прикрепил файл. Я немного анонимизировал его с помощью hex-редактора, надеюсь, не испортил. Быстрый просмотр говорит, что всё в порядке. Мой PD больше не меняется (раньше менялся каждые несколько дней), так что не хочу выставлять это напоказ. Мой IPv6-фильтр на фаерволе показывает, что меня ещё никто не нашёл, хотелось бы, чтобы так и осталось. eth1_2018-2-16_dhcpv6_ipv6only1.pcap.gz (1.56 KB) <br />
			<i>17.02.2018 04:59:00, acruhl.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388836</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388836</guid>
			<pubDate>Sat, 17 Feb 2018 04:59:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388835">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Если вы выложите PCAP, я с радостью его посмотрю. У меня пока не было возможности собрать свой. <br />
			<i>16.02.2018 14:59:00, idlemind.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388835</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388835</guid>
			<pubDate>Fri, 16 Feb 2018 14:59:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388834">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Я создал заявку в поддержку три недели назад. К сожалению, до сих пор не получил никакого ответа. <br />
			<i>16.02.2018 07:42:00, awm1.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388834</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388834</guid>
			<pubDate>Fri, 16 Feb 2018 07:42:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388833">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Да, я готов предоставить PCAP-файлы с сообщениями о запросах и рекламой. <br />
			<i>17.01.2018 20:41:00, idlemind.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388833</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388833</guid>
			<pubDate>Wed, 17 Jan 2018 20:41:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388832">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Лучше тогда создать заявку в службу поддержки MT, чтобы это исправили? <br />
			<i>17.01.2018 20:09:00, sebastia.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388832</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388832</guid>
			<pubDate>Wed, 17 Jan 2018 20:09:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388831">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Хм, если бы я мог увидеть захват пакетов цикла запроса DHCPv6, можно было бы точно понять, где именно ошибка. В RFC3633 (пункт 6) говорится: Identity Association for Prefix Delegation — IA_PD это конструкция, с помощью которой делегирующий маршрутизатор и запрашивающий маршрутизатор могут идентифицировать, группировать и управлять набором связанных IPv6-префиксов. Каждый IA_PD состоит из IAID и связанной с ним конфигурационной информации. &gt; IA_PD для префиксов — это эквивалент IA (описанного в RFC 3315) для адресов.<br /><br />Итак, если клиент отправляет один SOLICIT, в котором есть и IA_NA, и IA_PD как опции, сервер должен вернуть их в сообщении advertise. В RFC3315 (раздел 17.2.2) сказано: сервер включает в ответные опции, которые вернёт клиенту в следующем Reply. Информация из этих опций может помочь клиенту выбрать сервер, если он получит несколько Advertise. Если клиент в Solicit включил Option Request, сервер включает в Advertise параметры по всем опциям из запроса, которые настроен возвращать клиенту. Сервер может добавить и другие опции, если это предусмотрено. Сервер должен учитывать рекомендации по размеру пакетов и использование фрагментации из раздела 5 RFC 2460. Если Solicit содержит одну или несколько IA опций, сервер ОБЯЗАН включить IA опции в Advertise с любыми адресами, которые будут назначены IA из Solicit. Если клиент уже указал адреса в IA в Solicit, сервер использует их как подсказку, какие адреса клиент хотел бы получить.<br /><br />Быстрый взгляд подсказывает, что ошибка скорее всего на стороне DHCPv6 клиента на MikroTik. Позвольте показать своё ошарашенное лицо. <br />
			<i>17.01.2018 19:19:00, idlemind.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388831</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388831</guid>
			<pubDate>Wed, 17 Jan 2018 19:19:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388830">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			К сожалению, эта проблема всё ещё сохраняется в версии 6.41. Думаю, что опции IA_NA распознаются как опции IA_PD (согласно: «обрабатывается только назначение префикса, остальные отбрасываются»). Я пытался использовать Kea v1.2, но там формат сообщений такой же, как в v1.1. <br />
			<i>17.01.2018 16:43:00, awm1.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388830</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388830</guid>
			<pubDate>Wed, 17 Jan 2018 16:43:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388829">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Что конкретно ты рассматриваешь? Я снял дамп DHCPv6-запроса в Wireshark, но мне сложно сопоставить то, что вижу в пакете, с тем, что ты выложил здесь из RFC. IA я точно вижу, просто не уверен, что всё правильно. <br />
			<i>16.02.2018 13:50:00, acruhl.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388829</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388829</guid>
			<pubDate>Fri, 16 Feb 2018 13:50:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Проблема с DHCPv6 клиентом</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388828">Проблема с DHCPv6 клиентом</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			У меня возникла проблема с клиентом ROS DHCPv6. Мы используем ISC Kea для выдачи как статически назначенных IPv6-адресов, так и префиксов подсетей для клиентских устройств. На Kea версии 1.0 всё работало нормально — и устройства TP-Link, и RouterBoard получали свои адреса и префиксы. Но когда я попытался перейти на Kea версии 1.1, устройства RouterBoard внезапно перестали получать конфигурацию. В их логе полно таких сообщений:<br /><br />13:12:58 dhcp,debug,packet recv server: server1 fe80::2ca0:e376:b2b0:ee5c -&gt; ff02::1:2 &nbsp;<br />13:12:58 dhcp,debug,packet type: solicit &nbsp;<br />13:12:58 dhcp,debug,packet transaction-id: fa2c1f &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; clientid: &nbsp;00010001 1e1019bc 74d4358a 59ef &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; ia_na: &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp; &nbsp;t1: 0 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp; &nbsp;t2: 0 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp; &nbsp;id: 0x1674d435 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; oro: 17 23 24 39 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; elapsed_time: 15 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; vendor_class: &nbsp;00000137 00084d53 46542035 2e30 &nbsp;<br />13:12:58 dhcp,debug,packet &nbsp;-&gt; unknown: &nbsp;000e4157 4d2d5749 4e2d5345 52564552 &nbsp;<br />13:12:58 dhcp,debug handling only prefix delegation, discarding..<br /><br />Конфигурационные файлы для обеих версий Kea одинаковые. Но механизм ответа DHCPv6 изменился — Kea v1.0 отправляет отдельные ответы для адреса и префиксного делегирования, а v1.1 отправляет их в одном ответе. Вот вывод из отладочного лога Kea:<br /><br />Kea v1.0: &nbsp;<br />2017-03-08 13:57:32.154 DEBUG [kea-dhcp6.packets/33688] DHCP6_RESPONSE_DATA отвечаем пакетным типом 7, локальный адрес=[ff02::1:2]:547, удалённый=[fe80::4aee:cff:fef2:404a]:546  <br />msgtype=7, transid=0xb4b06f &nbsp;<br />type=00001, len=00010: 00:03:00:01:48:ee:0c:f2:40:4a &nbsp;<br />type=00002, len=00014: 00:01:00:87:20:52:bb:92:0c:c4:7a:80:2e:1b &nbsp;<br />type=00003(IA_NA), len=00040: iaid=202317888, t1=1800, t2=2880, &nbsp;<br />options: &nbsp;<br /> &nbsp;type=00005(IAADDR), len=00024: address=xxx:yyy:zzz:9d6:4aee:cff:fef2:404a, preferred-lft=3000, valid-lft=4000 &nbsp;<br />type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2 &nbsp;<br /><br />... немного другого отладочного вывода, опущено ...<br /><br />2017-03-08 13:57:32.155 DEBUG [kea-dhcp6.packets/33688] DHCP6_RESPONSE_DATA отвечаем пакетным типом 7, локальный адрес=[ff02::1:2]:547, удалённый=[fe80::4aee:cff:fef2:404a]:546  <br />msgtype=7, transid=0xcc87f7 &nbsp;<br />type=00001, len=00010: 00:03:00:01:48:ee:0c:f2:40:4a &nbsp;<br />type=00002, len=00014: 00:01:00:87:20:52:bb:92:0c:c4:7a:80:2e:1b &nbsp;<br />type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2 &nbsp;<br />type=00025(IA_PD), len=00041: iaid=202317888, t1=1800, t2=2880, &nbsp;<br />options: &nbsp;<br /> &nbsp;type=00026(IAPREFIX), len=00025: prefix=xxx:yyy:zzz:bb0a::/64, preferred-lft=3000, valid-lft=4000<br /><br />Kea v1.1: &nbsp;<br />2017-03-08 13:29:18.822 DEBUG [kea-dhcp6.packets/3895] DHCP6_RESPONSE_DATA отвечаем пакетным типом 2, локальный адрес=[ff02::1:2]:547, удалённый=[fe80::4e5e:cff:fef0:23bf]:546  <br />msgtype=2, transid=0xb8cb66 &nbsp;<br />type=00001, len=00010: 00:03:00:01:4c:5e:0c:f0:23:bf &nbsp;<br />type=00002, len=00014: 00:01:00:87:20:52:b4:fb:00:25:90:46:58:29 &nbsp;<br />type=00003(IA_NA), len=00040: iaid=2, t1=1800, t2=2880, &nbsp;<br />options: &nbsp;<br /> &nbsp;type=00005(IAADDR), len=00024: address=xxx:yyy:zzz:7e4:4e5e:cff:fef0:23bf, preferred-lft=3000, valid-lft=4000 &nbsp;<br />type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2 &nbsp;<br />type=00025(IA_PD), len=00041: iaid=2, t1=1800, t2=2880, &nbsp;<br />options: &nbsp;<br /> &nbsp;type=00026(IAPREFIX), len=00025: prefix=xxx:yyy:zzz:30a::/64, preferred-lft=3000, valid-lft=4000<br /><br />Конфигурация клиентов RB выглядит так: &nbsp;<br />/ipv6 dhcp-server &nbsp;<br />add address-pool=LAN-pool interface=LAN-bridge name=server1 &nbsp;<br />/ipv6 address &nbsp;<br />add from-pool=LAN-pool interface=ether2 &nbsp;<br />/ipv6 dhcp-client &nbsp;<br />add add-default-route=yes interface=ether1 pool-name=LAN-pool request=address,prefix &nbsp;<br />/ipv6 nd &nbsp;<br />add advertise-dns=yes hop-limit=64 interface=ether2 managed-address-configuration=yes<br /><br />Я уже пробовал ROS версий 6.34 - 6.38.3, и ни одна из них не работает с Kea v1.1, так что вряд ли это откат в ходе развития ROS. Тем не менее, хочу спросить — может ли проблема быть в ROS или в самом Kea-сервере? <br />
			<i>08.03.2017 13:25:00, awm1.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388828</link>
			<guid>http://mikrotik.moscow/forum/forum57/84658-problema-s-dhcpv6-klientom/message388828</guid>
			<pubDate>Wed, 08 Mar 2017 13:25:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
	</channel>
</rss>
