rfc2136 IPv6 with zoneID

[Thantalos]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug
OpnSense version: 26.1.2_5
os-rfc2136 version: 1.9_5

I can use the plugin to update a IPv4 on my server just fine, but if I activate IPv6 in the plugin, the DNS update fails. I assume that the origin of the problem lies with the IPv6. In the display of the plugin, the IPv6 is shown to include a zone ID. In my case the IP looks like this: fe80::1234:1234:1234:1234%pppoe0 (the zone ID is the percent sign and the interface name following it).
If I understand the source of the plugin correctly, this is also the IP it tries to send to the server, which clearly does not apply here and causes the update to fail.

To Reproduce
I am not sure why OpnSense does include the zone ID with the IPv6. Otherwise changing this would be a viable work around.

Expected behavior
The plugin should strip zone IDs from IPv6.

Relevant log files
This plugin does not seem to write a lot of log entries.

Additional context
The connection the IPv6 originates from is, as the name suggests, a PPPoE connection to my ISP.

[Monviech]

This is a link local address with scope ID

fe80::1234:1234:1234:1234%pppoe0

You need a GUA (Global Unicast Address). Does it exist on pppoe0?

[Thantalos]

I am a bit unsure about IPv6 ranges, that's why I included the first bit. When i connect to my OpnSense and run ifconfig (i could not find a similiar output in the GUI), I get three addresses for pppoe0. Two starting with fe80 and ending in %pppoe0 and one which at least shares the same beginning as my public IPc6. This IPv6 looks similiar to: 2003:e9:5fff:1234:1234:1234:1234:1234 - without a zone ID.

[Monviech]

Yup the one without scope id is your GUA (2003...), thats the one the plugin should theoretically use in dyndns updates.

It should also theoretically skip any link local (fe8...) addresses.

If it does not, there might be a bug and we should ping the maintainer of it.