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 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: mxhajducze...@gmail.com <mxhajducze...@gmail.com>
Date: Tuesday, April 23, 2024 at 9:56 AM
To: 'Kea user's list' <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 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@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: mxhajducze...@gmail.com <mxhajducze...@gmail.com>
Sent: Tuesday, April 23, 2024 9:42 AM
To: 'Kea user's list' <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 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@server-kea-node1:/home/kea# nmap localhost
Starting Nmap 7.80 ( https://nmap.org ) 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.
[cid:image001.png@01DA9563.FB2640A0]
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
https://lists.isc.org/mailman/listinfo/kea-users
