Topics

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

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?

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

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,

I have my Opnsense 23.1.5_4 configured for IPv6 Router Advertisements as Managed, as I have separate pair of Kea Servers handling IPv6. I noticed that a Windows 10 PC was using SLAAC to automatically generate its own IP address.

When I performed a packet capture I found that the SLAAC Router Advertisements were coming from the Opnsense which I specifically had disabled by configuring as Managed.

I presume this is a bug.

I have updated to include the packet capture despite the Router Flags set to Managed and the Opnsense dhcp server being disabled it includes the Network Prefix to cause clients to generate their own SLAAC address

Hi,

Would it be possible for the System Packet information after selecting an interface, the packet graphs would split IPv4 so it displays IPv4 vertically above the line and IPv6 below the line to the same scale. So visually it is easy to compare IPv4 and IPv6 traffic volume.