ISC DHCPv6-BIND9 DDNS update problem

Tue Jun 21 07:34:24 UTC 2022

Hi all,

It seems that I have been lucky this morning.

According to this article: 
https://www.mail-archive.com/kea-users@lists.isc.org/msg00467.html

 From this I got the notion that "The parameter is incorrect" message 
could come from incorrect
settings of DHCPv6 daemon.

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.

Here is the proof that the setup works now:

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
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
Jun 21 09:08:43 domac dhcpd: ddns.c(150): Allocating ddns_cb=0x55a466995360
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
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_fwd
Jun 21 09:08:43 domac dhcpd: DDNS: build_fwd_add1: 
pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
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
: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
Jun 21 09:08:43 domac dhcpd: ddns.c(1722): Updating lease_ptr for 
ddns_cp=0x55a466995360 (addr=2001:b68:2:2a00::10c4)
Jun 21 09:08:43 domac dhcpd: Sending Relay-reply to 
2001:b68:ff:ff:a2b:0:a8:2 port 547
Jun 21 09:08:43 domac named[357]: zone slava.alu.hr/IN/internal: sending 
notifies (serial 2022061542)
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338, result: 
success
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
Jun 21 09:08:43 domac dhcpd: Added new forward map from 
PC-PAVAO.slava.alu.hr to 2001:b68:2:2a00::10c4
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_ptr
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
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
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)
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338, result: 
success
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

I have solved the rogue DHCPv6 servers problem by assigning our main 
DHCPv6 server the highest preference (255).

Thank you for all the help and the suggestions.
It is really an excellent piece of software but it could have saved me 
weeks if it had parameter sanity checks. :-/

However, this excellent support community gave me the notion not to quit 
but to persevere despite the odds.

Kind regards,
Mirsad

On 21.6.2022. 8:53, Mirsad Goran Todorovac wrote:

> Hi all,
>
> Still no solution.
>
> However, we made it to work over a MikroTik DHCPv6 relay, partially.
> But what I get at the Windows 10 PC when I do an "IPCONFIG /RENEW6" is:
>
> An error occurred while renewing interface Ethernet : The parameter is 
> incorrect.
>
> The Wireshark shows that the MAC of the client is relayed to the 
> DHCPv6 server at the central hub,
> lease is picked from the pool for the appropriate location 
> [2001:b68:2:2a00::/64], and the DHCPv6
> relay makes an advertisement of the address to the Windows 10 client:
>
>
> However, the parameters are somehow not good and rejected. Server 
> tries up to 10 times with Advertise packet, but receives no Confirm.
>
> 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?
>
> default-lease-time 86400;
> preferred-lifetime 604800;
> option dhcp-renewal-time 3600;
> option dhcp-rebinding-time 7200;
> allow leasequery;
> option dhcp6.name-servers 2001:b68:2:2800::3,2001:b68:c:2::70:0;
> option dhcp6.domain-search "alu.hr";
> option dhcp6.preference 255;
> ##option dhcp6.rapid-commit;
> option dhcp6.info-refresh-time 21600;
>
> 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.
>
> There is no Confirm packet from either local link or relay clients, 
> equally Windows and Linux hosts, default setups.
>
> Thank you for any idea.
> I seem to be stuck with this, though there are small steps in the 
> right direction.
>
> Kind regards,
> Mirsad
>
> On 14.6.2022. 9:27, Mirsad Todorovac wrote:
>> On 6/10/22 19:14, Simon wrote:
>>
>>>
>>>> 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.
>>> 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.
>>>
>>> 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.)
>>
>> Hi, Simon,
>>
>> There is a quote that says that it is wrong to attributed to active 
>> sabotaging what can be explained with neglect and stupidity.
>>
>> 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.
>>
>> Regards,
>> Mirsad
>>
> -- 
> 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
>
-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220621/64393889/attachment-0001.htm>