ISC DHCPv6-BIND9 DDNS update problem

[Mirsad Goran Todorovac]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220621/4b48de01/attachment.htm>