<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all,</p>
<p>It seems that I have been lucky this morning.</p>
<p>According to this article:
<a class="moz-txt-link-freetext" href="https://www.mail-archive.com/kea-users@lists.isc.org/msg00467.html">https://www.mail-archive.com/kea-users@lists.isc.org/msg00467.html</a></p>
<p>From this I got the notion that "The parameter is incorrect"
message could come from incorrect<br>
settings of DHCPv6 daemon.</p>
<p>The problem was that default-lease-time was set to a value
shorter than the rest of the timeouts, which was obviously not
accepted by DHCPv6 clients even when accepted by DHCPv6 server and
relay.</p>
<p>Here is the proof that the setup works now:<br>
</p>
<p><font face="monospace">Jun 21 09:08:43 domac dhcpd: Relay-forward
message from 2001:b68:ff:ff:a2b:0:a8:2 port 547, link address
2001:b68:2:2a00::1, peer address fe80::51e5:1df6:c605:a036<br>
Jun 21 09:08:43 domac dhcpd: Reply NA: address
2001:b68:2:2a00::10c4 to client with duid
00:01:00:01:25:c4:85:9c:1c:a0:b8:7d:11:aa iaid = 102539448 valid
for 2592000 seconds<br>
Jun 21 09:08:43 domac dhcpd: ddns.c(150): Allocating
ddns_cb=0x55a466995360<br>
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_fwd_srv_connector:
ddns_cb: 0x55a466995360 flags: 103 state: DDNS_STATE_CLEANUP
cur_func: <null> eresult: 0<br>
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_fwd<br>
Jun 21 09:08:43 domac dhcpd: DDNS: build_fwd_add1:
pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]<br>
Jun 21 09:08:43 domac dhcpd: DDNS request: id ptr 0x7f799160c338
DDNS_STATE_ADD_FW_NXDOMAIN 2001:b68:2:2a00::10c4 for
PC-PAVAO.slava.alu.hr zone: slava.alu.hr.dhcid: [00:02:01<br>
:de:c5:41:4f:69:a0:e4:65:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6<br>
Jun 21 09:08:43 domac dhcpd: ddns.c(1722): Updating lease_ptr
for ddns_cp=0x55a466995360 (addr=2001:b68:2:2a00::10c4)<br>
Jun 21 09:08:43 domac dhcpd: Sending Relay-reply to
2001:b68:ff:ff:a2b:0:a8:2 port 547<br>
Jun 21 09:08:43 domac named[357]: zone slava.alu.hr/IN/internal:
sending notifies (serial 2022061542)<br>
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338,
result: success<br>
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_fwd_srv_add1: ddns_cb:
0x55a466995360 flags: 103 state: DDNS_STATE_ADD_FW_NXDOMAIN
cur_func: ddns_fwd_srv_add1 eresult: 0<br>
Jun 21 09:08:43 domac dhcpd: Added new forward map from
PC-PAVAO.slava.alu.hr to 2001:b68:2:2a00::10c4<br>
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_ptr<br>
Jun 21 09:08:43 domac dhcpd: DDNS request: id ptr 0x7f799160c338
DDNS_STATE_ADD_PTR PC-PAVAO.slava.alu.hr for
4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.i<br>
p6.arpa. zone: 0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.dhcid:
[00:02:01:de:c5:41:4f:69:a0:e4:65:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6<br>
Jun 21 09:08:43 domac named[357]: zone
0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa/IN/internal: sending
notifies (serial 2022060202)<br>
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338,
result: success<br>
Jun 21 09:08:43 domac dhcpd: Added reverse map from
4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.
to PC-PAVAO.slava.alu.hr<br>
</font></p>
<p>I have solved the rogue DHCPv6 servers problem by assigning our
main DHCPv6 server the highest preference (255).</p>
<p>Thank you for all the help and the suggestions.<br>
It is really an excellent piece of software but it could have
saved me weeks if it had parameter sanity checks. :-/</p>
<p>However, this excellent support community gave me the notion not
to quit but to persevere despite the odds.<br>
</p>
<p>Kind regards,<br>
Mirsad<br>
</p>
<p>On 21.6.2022. 8:53, Mirsad Goran Todorovac wrote:<br>
</p>
<blockquote type="cite"
cite="mid:76258929-1b1f-aa0b-ce72-bad1c8b8b72b@alu.unizg.hr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi all,</p>
<p>Still no solution.</p>
<p>However, we made it to work over a MikroTik DHCPv6 relay,
partially.<br>
But what I get at the Windows 10 PC when I do an "IPCONFIG
/RENEW6" is:</p>
<p><span
style="font-size:10pt;font-family:Consolas,Courier,monospace;">An
error occurred while renewing interface Ethernet : The
parameter is incorrect.</span></p>
<div class="moz-cite-prefix">The Wireshark shows that the MAC of
the client is relayed to the DHCPv6 server at the central hub,<br>
lease is picked from the pool for the appropriate location
[2001:b68:2:2a00::/64], and the DHCPv6</div>
<div class="moz-cite-prefix">relay makes an advertisement of the
address to the Windows 10 client:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><img data-imagetype="AttachmentByCid"
data-custom="AQMkAGVmMTIwNzhmLTg3YTQtNGM1Zi1hMDZhLWI0ZjEyNzFiMGUyYQBGAAAD8U1S1vZ1HkmNW54%2FeoqdnwcAkGGcN0tqeU2zAeOKSypPNgAAAgEJAAAAkGGcN0tqeU2zAeOKSypPNgAFmCIntAAAAAESABAA5wblApwF8UiFTDoPQ8nnHw%3D%3D"
src="https://attachments.office.net/owa/mtodorov%40grf.hr/service.svc/s/GetAttachmentThumbnail?id=AQMkAGVmMTIwNzhmLTg3YTQtNGM1Zi1hMDZhLWI0ZjEyNzFiMGUyYQBGAAAD8U1S1vZ1HkmNW54%2FeoqdnwcAkGGcN0tqeU2zAeOKSypPNgAAAgEJAAAAkGGcN0tqeU2zAeOKSypPNgAFmCIntAAAAAESABAA5wblApwF8UiFTDoPQ8nnHw%3D%3D&thumbnailType=2&token=eyJhbGciOiJSUzI1NiIsImtpZCI6IkZBRDY1NDI2MkM2QUYyOTYxQUExRThDQUI3OEZGMUIyNzBFNzA3RTkiLCJ0eXAiOiJKV1QiLCJ4NXQiOiItdFpVSml4cThwWWFvZWpLdDRfeHNuRG5CLWsifQ.eyJvcmlnaW4iOiJodHRwczovL291dGxvb2sub2ZmaWNlLmNvbSIsInVjIjoiMWM4YzdjMjRjNGQzNDRhNjhiNDhkM2VjNzI1OTJhOTAiLCJ2ZXIiOiJFeGNoYW5nZS5DYWxsYmFjay5WMSIsImFwcGN0eHNlbmRlciI6Ik93YURvd25sb2FkQDZhYjA0NjQ5LWJkZmEtNDA2ZS1hMjMyLTk1NjRiZGU2ZjVmYiIsImlzc3JpbmciOiJXVyIsImFwcGN0eCI6IntcIm1zZXhjaHByb3RcIjpcIm93YVwiLFwicHVpZFwiOlwiMTE1MzgzNjI5NjQ5MDgzMjEzM1wiLFwic2NvcGVcIjpcIk93YURvd25sb2FkXCIsXCJvaWRcIjpcIjAxYTcyZGVkLWJlMTUtNDQ4Zi1iZDIwLTRjYmI4YTRiZWNiMlwiLFwicHJpbWFyeXNpZFwiOlwiUy0xLTUtMjEtMTIxODkzMDM5My0yNTA4ODk3NDMwLTMzNTY2MjA3NzctMTk3MjA3XCJ9IiwibmJmIjoxNjU1NzkzNDkxLCJleHAiOjE2NTU3OTQwOTEsImlzcyI6IjAwMDAwMDAyLTAwMDAtMGZmMS1jZTAwLTAwMDAwMDAwMDAwMEA2YWIwNDY0OS1iZGZhLTQwNmUtYTIzMi05NTY0YmRlNmY1ZmIiLCJhdWQiOiIwMDAwMDAwMi0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDAvYXR0YWNobWVudHMub2ZmaWNlLm5ldEA2YWIwNDY0OS1iZGZhLTQwNmUtYTIzMi05NTY0YmRlNmY1ZmIiLCJoYXBwIjoib3dhIn0.C_RbgDA_dtEfvEjM1PNVldExSNZ4KZnyK7iONEbBr_BuNphVYySyQOyTwzi3ZVsclhO9cY9iowVjkyQqaNWUEpyuAtmNXW-T0ohGxsIozbu0To6yZhhR72WdZxbBN-3OPx78OlHpa8EJ8bWdpcvZTV16FWjCMOet7IlDg7iRKs8aKU3YBnpuzjYWo7UnptdnsmKtoGZBcbaOq2wC5hii1b7w5H7FtIvygTKcbZOmiSyKDH32Ox_MmBBaILt2HnJZZyEj0S70di9iDOLXap6bNA5zu4MSOsWhiom5UBP8wW2GVKyMN0exvM45BR6_W1FGGPqRa2C1slWQF9LykTCHBQ&X-OWA-CANARY=TaqFXcGnkk2C9xsP7Imb-PB_iJ1QU9oYNnYtijGfw-I-wRlYyRQjEQpx0xQi5Jjh2DpIh5VWaBc.&owa=outlook.office.com&scriptVer=20220610006.04&animation=true"
data-outlook-trace="F:3|T:3" size="14667" style="max-width:
100%; cursor: pointer; min-width: auto; min-height: auto;
height: auto;" crossorigin="use-credentials" class="ADIae"
moz-do-not-send="true"></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">However, the parameters are somehow
not good and rejected. Server tries up to 10 times with
Advertise packet, but receives no Confirm.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I've seen an article on the list
about Kea parms causing this. Can it be that I have set an
impossible set of DHCPv6 parameters?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">default-lease-time 86400;<br>
preferred-lifetime 604800;<br>
option dhcp-renewal-time 3600;<br>
option dhcp-rebinding-time 7200;<br>
allow leasequery;<br>
option dhcp6.name-servers 2001:b68:2:2800::3,2001:b68:c:2::70:0;<br>
option dhcp6.domain-search "alu.hr";<br>
option dhcp6.preference 255;<br>
##option dhcp6.rapid-commit;<br>
option dhcp6.info-refresh-time 21600;<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The symptom is the same over the
local subnet and over the DHCPv6 relay: the address is allocated
from the pool, Advertised 10x and then the ISC DHCPv6 server
gives up.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">There is no Confirm packet from
either local link or relay clients, equally Windows and Linux
hosts, default setups.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thank you for any idea.<br>
I seem to be stuck with this, though there are small steps in
the right direction.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Kind regards,<br>
Mirsad<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 14.6.2022. 9:27, Mirsad Todorovac
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7730ca86-dbf0-4d51-ad21-610037ae1ddb@alu.unizg.hr">On
6/10/22 19:14, Simon wrote: <br>
<br>
<blockquote type="cite"> <br>
<blockquote type="cite">Unfortunately, I am not even the admin
of all those net segments and rogue devices. I might be
simply out of luck with this one. <br>
</blockquote>
Presumably you know the network admins who are responsible for
those segments ? And presumably there must be a person or
group which oversees the network as a whole (subnets/prefixes
etc) ? Just letting everyone “do their own thing” without
central planning is a recipe for disaster. <br>
<br>
So you need to go to them and point out what the problem is,
and what needs to be done to fix it. Of course, if they don’t
want to then you’re down to internal politics and potentially
you end up reporting back to management that you can’t
implement what’s asked for because others are actively
sabotaging the network (that’s how I’d describe it if supposed
network admins are doing nothing to deal with rogue services
like this.) <br>
</blockquote>
<br>
Hi, Simon, <br>
<br>
There is a quote that says that it is wrong to attributed to
active sabotaging what can be explained with neglect and
stupidity. <br>
<br>
I believe in the most cases these are simply the default
settings for the devices. Probably someone in those companies
thinks that it is a good idea to have a dozen of DHCPv6 servers
who do not talk to each other and have no ideas of other
server's IPv6 range - all on the same subnet. <br>
<br>
Regards, <br>
Mirsad <br>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
Mirsad Todorovac
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
Mirsad Todorovac
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu</pre>
</body>
</html>