Messages

After a bit of research the following does appear to produce consistent results by selecting JSON output.
Write to temporary file to minimise calls to rdap

$ rdap -j -t ip <random-ip>  > /tmp/RDAP

Registrant     $ cat /tmp/RDAP | jq '.remarks | .[] .description'
Country        $ cat /tmp/RDAP | jq '.country'
Start IP         $ cat /tmp/RDAP | jq '.startaddress'
End IP          $ cat /tmp/RDAP | jq '.endAddress'

 I found that the registrant details could be obtained using the following filter "grep fn"

$ rdap -t ip <random ip> | grep fn

Unfortunately while multiple lines are returned, in most cases the 1st line is the Registrant Name
 
$ rdap -t ip <random ip> | grep fn | head -n 1

However this is not always the case, with some Registrants it is the 2nd or 3rd line where the Registrant Name is provided

All requests globally can be achieved via a web query to https://rdap.org/<query-type>/<query> or more likely if using the linux rdap cli tool does the https query for you. All that is required for example "rdap -t ip <ipv4/ipv6 address>

$ rdap -h
OpenRDAP v0.9.1
(www.openrdap.org)

Usage: rdap [OPTIONS] DOMAIN|IP|ASN|ENTITY|NAMESERVER|RDAP-URL
  e.g. rdap example.cz
       rdap 192.0.2.0
       rdap 2001:db8::
       rdap AS2856
       rdap https://rdap.nic.cz/domain/example.cz

       rdap -f registrant -f administrative -f billing amazon.com.br
       rdap --json https://rdap.nic.cz/domain/example.cz
       rdap -s https://rdap.nic.cz -t help

Options:
  -h, --help          Show help message.
  -v, --verbose       Print verbose messages on STDERR.

  -T, --timeout=SECS  Timeout after SECS seconds (default: 30).
  -k, --insecure      Disable SSL certificate verification.

  -e, --experimental  Enable some experimental options:
                      - Use the bootstrap service https://test.rdap.net/rdap
                      - Enable object tag support

Authentication options:
  -P, --p12=cert.p12[:password] Use client certificate & private key (PKCS#12 format)
or:
  -C, --cert=cert.pem           Use client certificate (PEM format)
  -K, --key=cert.key            Use client private key (PEM format)

Output Options:
      --text          Output RDAP, plain text "tree" format (default).
  -w, --whois         Output WHOIS style (domain queries only).
  -j, --json          Output JSON, pretty-printed format.
  -r, --raw           Output the raw server response.

Advanced options (query):
  -s  --server=URL    RDAP server to query.
  -t  --type=TYPE     RDAP query type. Normally auto-detected. The types are:
                      - ip
                      - domain
                      - autnum
                      - nameserver
                      - entity
                      - help
                      - url
                      - domain-search
                      - domain-search-by-nameserver
                      - domain-search-by-nameserver-ip
                      - nameserver-search
                      - nameserver-search-by-ip
                      - entity-search
                      - entity-search-by-handle
                      The servers for domain, ip, autnum, url queries can be
                      determined automatically. Otherwise, the RDAP server
                      (--server=URL) must be specified.

Advanced options (bootstrapping):
      --cache-dir=DIR Bootstrap cache directory to use. Specify empty string
                      to disable bootstrap caching. The directory is created
                      automatically as needed. (default: $HOME/.openrdap).
      --bs-url=URL    Bootstrap service URL (default: https://data.iana.org/rdap)
      --bs-ttl=SECS   Bootstrap cache time in seconds (default: 3600)

Advanced options (experiments):
      --exp=test_rdap_net  Use the bootstrap service https://test.rdap.net/rdap
      --exp=object_tag     Enable object tag support
                           (draft-hollenbeck-regext-rdap-object-tag)

As you can see the rdap command has many options and rdap is the replacement for whois.
The key information for display is the Network Registrant in the tab, if an IP address is associated with a large corporation like Microsoft then traffic can be categorised by Organisation.

Within the Reporting -> Insight -> Totals, add an additional option "Reverse Network Owner" so that when checked a Registration Data Access Protocol (RDAP) is made to retrieve the details of the Network registered user.  Here is the output of rdap

# rdap -t ip 34.117.223.223
IP Network:
  Handle: NET-34-64-0-0-1
  Start Address: 34.64.0.0
  End Address: 34.127.255.255
  IP Version: v4
  Name: GOOGL-2
  Type: DIRECT ALLOCATION
  ParentHandle: NET-34-0-0-0-0
  Status: active
  Port43: whois.arin.net
  Notice:
    Title: Terms of Service
    Description: By using the ARIN RDAP/Whois service, you are agreeing to the RDAP/Whois Terms of Use
    Link: https://www.arin.net/resources/registry/whois/tou/
  Notice:
    Title: Whois Inaccuracy Reporting
    Description: If you see inaccuracies in the results, please visit:
    Link: https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
  Notice:
    Title: Copyright Notice
    Description: Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
  Entity:
    Handle: GOOGL-2
    Port43: whois.arin.net
    Remark:
      Title: Registration Comments
      Description: *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
      Description:
      Description: Direct all copyright and legal complaints to
      Description: https://support.google.com/legal/go/report
      Description:
      Description: Direct all spam and abuse complaints to
      Description: https://support.google.com/code/go/gce_abuse_report
      Description:
      Description: For fastest response, use the relevant forms above.
      Description:
      Description: Complaints can also be sent to the GC Abuse desk
      Description: (google-cloud-compliance@google.com)
      Description: but may have longer turnaround times.
      Description:
      Description: Complaints sent to any other POC will be ignored.
    Link: https://rdap.arin.net/registry/entity/GOOGL-2
    Link: https://whois.arin.net/rest/org/GOOGL-2
    Event:
      Action: last changed
      Date: 2019-11-01T05:34:25-04:00
    Event:
      Action: registration
      Date: 2006-09-29T16:40:11-04:00
    Role: registrant
    vCard version: 4.0
    vCard fn: Google LLC
    vCard kind: org
    Entity:
      Handle: GCABU-ARIN
      Port43: whois.arin.net
      Remark:
        Title: Unvalidated POC
        Description: ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2022-04-09
      Link: https://rdap.arin.net/registry/entity/GCABU-ARIN
      Link: https://whois.arin.net/rest/poc/GCABU-ARIN
      Event:
        Action: last changed
        Date: 2021-04-09T11:46:04-04:00
      Event:
        Action: registration
        Date: 2011-03-30T00:36:28-04:00
      Role: abuse
      Role: noc
      vCard version: 4.0
      vCard fn: GC Abuse
      vCard org: GC Abuse
      vCard kind: group
      vCard email: google-cloud-compliance@google.com
      vCard tel: +1-650-253-0000
    Entity:
      Handle: ZG39-ARIN
      Status: validated
      Port43: whois.arin.net
      Link: https://rdap.arin.net/registry/entity/ZG39-ARIN
      Link: https://whois.arin.net/rest/poc/ZG39-ARIN
      Event:
        Action: last changed
        Date: 2024-11-11T04:27:09-05:00
      Event:
        Action: registration
        Date: 2000-11-30T13:54:08-05:00
      Role: administrative
      Role: technical
      vCard version: 4.0
      vCard fn: Google LLC
      vCard org: Google LLC
      vCard kind: group
      vCard email: arin-contact@google.com
      vCard tel: +1-650-253-0000
  Link: https://rdap.arin.net/registry/ip/34.64.0.0
  Link: https://whois.arin.net/rest/net/NET-34-64-0-0-1
  Event:
    Action: last changed
    Date: 2018-09-28T10:45:41-04:00
  Event:
    Action: registration
    Date: 2018-09-28T10:45:37-04:00
  cidr0_cidrs:
    v4prefix: 34.64.0.0
    length: 10

The RDAP information could be cached so that the start and end addesses, registered owner and country can be used for further traffic without requiring further calls, only upon reboot for example would be cache be cleared

Since upgrading to 25.1.10 Kea is providing IPv4 and IPv6 addresses without a problem, so I have stopped using ISC DHCP

Since upgrading to 25.1.10 Kea is providing IPv4 and IPv6 addresses without a problem, so I have stopped using ISC DHCP

Hi,
Upgraded to 25.1.8_1 and tried replacing ISC DHCPv4 and DHCPv6 with Kea DHCPv4 and DHCPv6.
When Kea DHCPv4 is configured with a RAW socket type, then I can see the DHCP interactions for both IPv4 and IPv6 on one VLAN but not the other, when I configure Kea DHCPv4 with a UDP socket then I can see DHCPv6 interactions but no DHCPv4 entries and my client does not obtain an IPv4 address. While my client can appear to renew its IPv6 address, the IPv4 address renewal fails.
My client on another VLAN there is no interaction recorded in the logs for IPv6 or IPv4 with the socket configured as RAW or UDP..
When I stop and start the Kea DHCPv4 service the logs report that it is the DHCPv6 service that has been restarted, should it report that DHCPv4 service has restarted?

Upgraded to 25.1.7_4 and checked out Kea DHCP operation, my laptop can obtain an IPv6 address however if fails to get an IPv4 address.
Checking KEA's information logs 

Code Select Expand

2025-05-24T13:02:39 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2b0007816d00] DHCP4_PACKET_SEND [hwtype=1 ab:ab:ab:ab:ab:ab], cid=[01:ab:ab:ab:ab:ab:ab], tid=0x4ae8d6a: trying to send packet DHCPOFFER (type 2) from 192.168.1.1:67 to 192.168.1.10:68 on interface lagg0_vlan2
2025-05-24T13:02:39 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x2b0007816d00] DHCP4_LEASE_OFFER [hwtype=1 ab:ab:ab:ab:ab:ab], cid=[01:ab:ab:ab:ab:ab:ab], tid=0x4ae8d6a: lease 192.168.1.10 will be offered
2025-05-24T13:02:39 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2b0007816d00] DHCP4_PACKET_RECEIVED [hwtype=1 ab:ab:ab:ab:ab:ab], cid=[01:ab:ab:ab:ab:ab:ab], tid=0x4ae8d6a: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface lagg0_vlan2
2025-05-24T13:02:39 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x2b0007816d00] DHCP4_QUERY_LABEL received query: [hwtype=1 ab:ab:ab:ab:ab:ab], cid=[01:ab:ab:ab:ab:ab:ab], tid=0x4ae8d6a
So the logs are indicating its trying to send an DHCPOFFER and my laptop does not receive the offer, given that ISC DHCP works and the network has not changed. Would there be an issue with the automated Firewall rules.

The other thing I have noticed with Kea, is that DHCPv6 leases which have exceeded their expiry date are still being displayed.

Tried 25.1.7_2 with Kea DHCPv6 and DHCPv4 and now even from a reboot while my laptop does get an IPv6 address it fails to get an IPv4 address, looking at the Kea DHCPv4 information logs only the DO portion of the DORA process completes. Like before my daughter's laptop did not obtain an IP address (IPv4 or IPv6).

After checking the KEA Logs (informational) with 25.1.6_4, after a power cycle the logs show my laptop communicating with KEA and obtaining an IPv6 address then after a brief period it shows the laptop going through the DORA process and obtaining IPv4 address. After restarting the KEA Service and power cycling the laptop, the logs show an IPv6 address SARR process, however the IPv4 only completes DO or DORA, an DHCPOFFER is sent but there is never any response.
In respect of my daughter's connection, I connected a laptop to her network connection and could not get an IPv6 or IPv4 address checking the logs it shows that for IPv6 it completes SA of SARR and DO or DORA. In both cases I am using automated firewall rules, checking them manually they appear to be correct.
Both VLANs are connected to LAG interface connecting the 25.1.6_4 to my switch.
Restoring the ISC DHCP backup and with the attendant reboot, everything works as normal. So it is not a network issue, it appears to be directly related to ISC Kea.

I have have two VLANs configured to seperate work traffic (myself and daughter) from home traffic. Currently I did have ISC DHCPv4 and DHCPv6 configured to supply both IPv4 and IPv6 traffic to work devices. After upgrading to 25.1.6_2 I performed a backup and then disabled ISC DHCPv4 and DHCPv6 and configured the same networks onto Kea DHCPv4 and DHCPv6. Initially with 25.1.6_2 I did managed to get an IPv4 and IPv6 address on my laptop but the lease did not appear. However after a power cycle the my laptop obtained an IPv4 and IPv6 address with both the IPv4 and IPv6 lease appearing; my daughter's laptop never obtained an IP address.
After upgrading to 25.1.6_4 I am able to obtain an IPv6 address but unable to obtain an IPv4 address, reverting to using ISC DHCP by restoring a backup IP addresses are always obtained.
If I power cycle 25.1.6_4 using the Kea backup, then my laptop does get IPv6 address immediately and then will get an IPv4 address, however only the IPv6 lease appears in Leases DHCPv6, nothing appears in Leases DHCPv4. If I restart the Kea DHCP service then I stop getting an IPv4 address and only obtain an IPv6 address

I have been running a pair of ISC Kea DHCPv4 and DHCPv6 servers on linux for over two years since ISC stopped maintaining ISC DHCP at the end of 2022. Personally very happy to switch because of the ISC Kea ability to handle DHCP Failover for DHCPv6 which was not supported in ISC DHCP.

Is it possible to modify or update to a later version the resource which is referenced by ARP table so that I can add missing Vendor mac prefix entries. Using maclookup.app I found that the 74:78:27 was assigned to Dell on 23rd September 2020, so it is not new being nearly three years old. Which raises the question how frequently the vendor mac prefix resource is updated.

Hi,
What I have found is that if a Router Advertisement includes a Network Prefix and an IPv6 client is configured with a static address, unless you configure the client to not accept router advertisements then the client will generate a SLAAC address if the Router Advertisement includes a network prefix.

The use of a network prefix is to inform the client to generate to either generate a SLAAC address or inform the client to use DHCPv6 stateful or stateless.

I found with Windows 2008 server configured with a static address, using RA I could get it to generate a SLAAC address. This was fixed in if I remember correctly in Server 2012 so it ignored the RA by default.

Hi

Great that you can disable autoconfiguration on your version of Windows 10.
Which version of Windows 10 are you testing? My wife's laptop Windows 10 will not disable Autoconfiguration.

Either way the Network Prefix should not be included in the Router Advertisement when Managed is selected and the DHCPv6 server on Opnsense is disabled.

The problem is that Autoconfiguration is enabled by default, on Linux it is easy to permanently disable acting on Router Advertisements but on Windows it is more problematic and all a rogue actor needs to do is to inject rogue router advertisements into an IPv6 network to cause havoc.