Thank you, Darren
I did find the other ticket which seems to have been open for 2 years (?): https://gitlab.isc.org/isc-projects/kea/-/issues/2212 and added my information to it. I can reproduce it now on demand on any nodes. As mentioned, the link local bind will work fine when DHCP clients are on the same L2 segment where link-local reachability is sufficient for routing purposes. It will not work in environment where relays are used, and unicast routing is required. This would be the case in Docker and also in my setup. Regards Marek From: Kea-users <kea-users-boun...@lists.isc.org> On Behalf Of Darren Ankney Sent: Wednesday, April 24, 2024 4:00 AM To: Kea user's list <kea-users@lists.isc.org> Subject: Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit messages This does not seem to be intended behavior: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#interface-configuration as this shows the following configurations all as valid: "interfaces-config": { "interfaces": [ "*" ] }, "interfaces-config": { "interfaces": [ "eth1", "eth3" ] }, "interfaces-config": { "interfaces": [ "eth1", "eth3", "*" ] }, "interfaces-config": { "interfaces": [ "enp0s2/2001:db8::1234:abcd" ] }, On Tue, Apr 23, 2024 at 7:04 PM Marek Hajduczenia <mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> > wrote: I have not been able to find a workaround for this problem on IPv6 side for now. Marek From: Kea-users <kea-users-boun...@lists.isc.org <mailto:kea-users-boun...@lists.isc.org> > On Behalf Of Butler, Glenn via Kea-users Sent: Tuesday, April 23, 2024 3:58 PM To: Kea user's list <kea-users@lists.isc.org <mailto:kea-users@lists.isc.org> > Cc: Butler, Glenn <glenn.but...@ziply.com <mailto:glenn.but...@ziply.com> > Subject: Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit messages I need to figure this out also, as I run Kea in a container that can be destroyed and rebuilt anytime. I am thinking I will update the Kea config via a shell script run on boot/init. Would be nice if there was a "listen on all" option like 0.0.0.0 does for IPv4, but all the docs I have read indicate that it only binds to one address. On Apr 23, 2024 09:26, Marek Hajduczenia <mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> > wrote: _____ WARNING: External email. Please verify sender before opening attachments or clicking on links. _____ So I think I found the potential solution, though I am not sure I understand why this happens. I had to specifically configure the unicast IPv6 address in the “interfaces” clause, as follows "interfaces-config": { "interfaces": [ "enp6s18/2600:6ce4:0:42::130" ] }, far from ideal, but it seems to force the association with the unicast IPv6 address (marked in yellow highlight below) root@server-kea-node1:/etc/kea# ss -tulpn Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 127.0.0.1:53001 <http://127.0.0.1:53001> 0.0.0.0:* users:(("kea-dhcp-ddns",pid=629,fd=13)) udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=610,fd=13)) udp UNCONN 0 0 172.17.129.130:67 <http://172.17.129.130:67> 0.0.0.0:* users:(("kea-dhcp4",pid=630,fd=17)) udp UNCONN 0 0 [2600:6ce4:0:42::130]:547 [::]:* users:(("kea-dhcp6",pid=2059,fd=17)) udp UNCONN 0 0 [fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:* users:(("kea-dhcp6",pid=2059,fd=18)) udp UNCONN 0 0 [ff02::1:2]%enp6s18:547 [::]:* users:(("kea-dhcp6",pid=2059,fd=19)) tcp LISTEN 0 4096 127.0.0.1:8000 <http://127.0.0.1:8000> 0.0.0.0:* users:(("kea-ctrl-agent",pid=628,fd=7)) tcp LISTEN 0 128 0.0.0.0:22 <http://0.0.0.0:22> 0.0.0.0:* users:(("sshd",pid=673,fd=3)) tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=610,fd=14)) tcp LISTEN 0 4096 *:9119 *:* users:(("stork-agent",pid=632,fd=8)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=673,fd=4)) tcp LISTEN 0 4096 *:8080 *:* users:(("stork-agent",pid=632,fd=9)) tcp LISTEN 0 4096 *:9547 *:* users:(("stork-agent",pid=632,fd=3) but this behavior does not seem to be documented anywhere. I did not find any indication that for v6 an explicit address allocation is also required, otherwise just the link local will be bound. Is this an expected behavior? Regards Marek From: mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> <mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> > Date: Tuesday, April 23, 2024 at 9:56 AM To: 'Kea user's list' <kea-users@lists.isc.org <mailto:kea-users@lists.isc.org> > Subject: RE: DHCPv6, shared network, and double-relay Solicit messages I guess netstat is deprecated. “ss” seems to show the binding but … only to a link local address for some reason on the v6 side. root@server-kea-node1:~# ss -tulpn Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 127.0.0.1:53001 <http://127.0.0.1:53001> 0.0.0.0:* users:(("kea-dhcp-ddns",pid=629,fd=13)) udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=610,fd=13)) udp UNCONN 0 0 172.17.129.130:67 <http://172.17.129.130:67> 0.0.0.0:* users:(("kea-dhcp4",pid=630,fd=17)) udp UNCONN 0 0 [fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:* users:(("kea-dhcp6",pid=1631,fd=17)) udp UNCONN 0 0 [ff02::1:2]%enp6s18:547 [::]:* users:(("kea-dhcp6",pid=1631,fd=18)) tcp LISTEN 0 4096 127.0.0.1:8000 <http://127.0.0.1:8000> 0.0.0.0:* users:(("kea-ctrl-agent",pid=628,fd=7)) tcp LISTEN 0 128 0.0.0.0:22 <http://0.0.0.0:22> 0.0.0.0:* users:(("sshd",pid=673,fd=3)) tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=610,fd=14)) tcp LISTEN 0 4096 *:9119 *:* users:(("stork-agent",pid=632,fd=8)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=673,fd=4)) tcp LISTEN 0 4096 *:8080 *:* users:(("stork-agent",pid=632,fd=9)) tcp LISTEN 0 4096 *:9547 *:* users:(("stork-agent",pid=632,fd=3)) The host does have unicast IPv6 address on it and the binding is done on specific interface. root@server-kea-node1:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether bc:24:11:a6:cc:be brd ff:ff:ff:ff:ff:ff inet 172.17.129.130/25 <http://172.17.129.130/25> brd 172.17.129.255 scope global enp6s18 valid_lft forever preferred_lft forever inet6 2600:6ce4:0:42::130/64 scope global valid_lft forever preferred_lft forever inet6 fe80::be24:11ff:fea6:ccbe/64 scope link valid_lft forever preferred_lft forever Regards Marek From: mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> <mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> > Sent: Tuesday, April 23, 2024 9:42 AM To: 'Kea user's list' <kea-users@lists.isc.org <mailto:kea-users@lists.isc.org> > Subject: RE: DHCPv6, shared network, and double-relay Solicit messages I wonder whether it has anything to do with the fact that DHCPv6 process does not seem to listen on port 546 root@server-kea-node1:/home/kea # sudo netstat -tulpn | grep LISTEN tcp 0 0 127.0.0.1:8000 <http://127.0.0.1:8000> 0.0.0.0:* LISTEN 628/kea-ctrl-agent tcp 0 0 0.0.0.0:22 <http://0.0.0.0:22> 0.0.0.0:* LISTEN 673/sshd: /usr/sbin tcp 0 0 127.0.0.53:53 <http://127.0.0.53:53> 0.0.0.0:* LISTEN 610/systemd-resolve tcp6 0 0 :::9119 :::* LISTEN 632/stork-agent tcp6 0 0 :::22 :::* LISTEN 673/sshd: /usr/sbin tcp6 0 0 :::8080 :::* LISTEN 632/stork-agent tcp6 0 0 :::9547 :::* LISTEN 632/stork-agent root@server-kea-node1:/home/kea# nmap localhost Starting Nmap 7.80 ( https://nmap.org <https://protect.checkpoint.com/v2/___https:/nmap.org___.YzJ1OnppcGx5ZmliZXI6YzpvOjZkYzY1Y2Y5MDliYzlmMGM0MTg5Zjc2NGVlMjYzMzQ1OjY6ZGFmOTowNDc5ZWVmYzVmY2FiM2NmMTU2MDk4Y2MxOGQ4MTFmMjdkNzY4YzNjZjgwZmQ0MTExZDVlZDM0OGEwZDQ4ZmZlOmg6VA> ) at 2024-04-23 15:35 UTC Nmap scan report for localhost (127.0.0.1) Host is up (0.0000030s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 8000/tcp open http-alt 8080/tcp open http-proxy Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds I do not see DHCPv4 or DHCPv6 ports open at all. Per manual, “The DHCPv4 and DHCPv6 protocols assume the server will open privileged UDP port 67 (DHCPv4) or 547 (DHCPv6).” , which is fine, I do start the DHCPv6 process as root, so it should show up in the list of ports being open. Marek From: mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> <mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com> > Sent: Tuesday, April 23, 2024 9:19 AM To: 'Kea user's list' <kea-users@lists.isc.org <mailto:kea-users@lists.isc.org> > Subject: DHCPv6, shared network, and double-relay Solicit messages Dear colleagues, I have been attempting to test a setup in the lab with DOCSIS CM operating in IPv6 mode only, where the DHCPv6 messages are relayed across the CMTS and the first-hop router (relay address 2600:6ce4:0:3e::1) towards a Kea server running 2.4 code (address 2600:6ce4:0:42::130). At the Kea server level, I ran a packet capture, to observe an interesting behavior – the Solicit messages from the DOCSIS CM are being forwarded back to the relay, embedded within the ICMPv6 message with indication that the destination is unreachable for some reason. The Kea server is running without any issues so it seems that the binding is successful and root@server-kea-node1:/home/ace# service isc-kea-dhcp6-server status ● isc-kea-dhcp6-server.service - Kea DHCPv6 Service Loaded: loaded (/lib/systemd/system/isc-kea-dhcp6-server.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2024-04-23 15:02:41 UTC; 11min ago Docs: man:kea-dhcp6(8) Main PID: 1551 (kea-dhcp6) Tasks: 7 (limit: 4550) Memory: 3.5M CPU: 119ms CGroup: /system.slice/isc-kea-dhcp6-server.service └─1551 /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf Apr 23 15:14:29 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:29.467 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_CONNECTION_OPENED Opened socket 22 for incoming command connection Apr 23 15:14:29 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:29.468 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_READ Received 129 bytes over command socket 22 Apr 23 15:14:29 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:29.468 INFO [kea-dhcp6.commands/1551.140682475032192] COMMAND_RECEIVED Received command 'statistic-get' Apr 23 15:14:29 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:29.468 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_WRITE Sent response of 92 bytes (0 bytes left to send) over command socket 22 Apr 23 15:14:29 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:29.468 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 22 for existing command connection Apr 23 15:14:30 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:30.158 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_CONNECTION_OPENED Opened socket 22 for incoming command connection Apr 23 15:14:30 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:30.158 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_READ Received 117 bytes over command socket 22 Apr 23 15:14:30 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:30.158 INFO [kea-dhcp6.commands/1551.140682475032192] COMMAND_RECEIVED Received command 'statistic-get-all' Apr 23 15:14:30 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:30.158 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_WRITE Sent response of 8715 bytes (0 bytes left to send) over command socket 22 Apr 23 15:14:30 server-kea-node1 kea-dhcp6[1551]: 2024-04-23 15:14:30.158 DEBUG [kea-dhcp6.commands/1551.140682475032192] COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 22 for existing command connection I attach the Kea DHCPv6 config for reference (keav6.json) – the test device should match rpd-10 class, and make its way into 2600:6ce4:0:3e::/64 subnet. I am drawing blank on what the problem might be in here. I have not seen this behavior before and I am not sure whether it is related with the fact that I have two layers of relays in messages or not Regards Marek -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/kea-users
-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
