[Kea-users] DHCPv6, shared network, and double-relay Solicit messages
Darren Ankney
darren.ankney at gmail.com
Wed Apr 24 10:00:10 UTC 2024
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 <mxhajduczenia at 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-bounces at 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 at lists.isc.org>
> *Cc:* Butler, Glenn <glenn.butler at 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 <mxhajduczenia at 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 at 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 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 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 0.0.0.0:*
> users:(("kea-ctrl-agent",pid=628,fd=7))
>
> tcp LISTEN 0
> 128 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: *mxhajduczenia at gmail.com <mxhajduczenia at gmail.com>
> *Date: *Tuesday, April 23, 2024 at 9:56 AM
> *To: *'Kea user's list' <kea-users at 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 at 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
> 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
> 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
> 0.0.0.0:* users:(("kea-ctrl-agent",pid=628,fd=7))
>
> tcp LISTEN 0
> 128 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 at 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 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 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:* mxhajduczenia at gmail.com <mxhajduczenia at gmail.com>
> *Sent:* Tuesday, April 23, 2024 9:42 AM
> *To:* 'Kea user's list' <kea-users at 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 at server-kea-node1:/home/kea # sudo netstat -tulpn | grep LISTEN
>
> tcp 0 0 127.0.0.1:8000 0.0.0.0:*
> LISTEN 628/kea-ctrl-agent
>
> tcp 0 0 0.0.0.0:22 0.0.0.0:*
> LISTEN 673/sshd: /usr/sbin
>
> tcp 0 0 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 at 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:* mxhajduczenia at gmail.com <mxhajduczenia at gmail.com>
> *Sent:* Tuesday, April 23, 2024 9:19 AM
> *To:* 'Kea user's list' <kea-users at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240424/71ad6dea/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 24639 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240424/71ad6dea/attachment-0001.png>
More information about the Kea-users
mailing list