Topics

Hi,
After trying to upgrade to 26.1 even using Option 12 on the console and it failing with truncated .sig files. After googling I found a suggestion to enable "Prefer to use IPv4 even if IPv6 available" immediately doing this the upgrade process was completely different when this option was not selected. A summary of the upgrade and its changed appeared which appears to be hosted on github based on forum post did not appear when the option was not selected. When I perform a dig for github.com it does not have an IPv6 address which explains why it did not appear.

dig @8.8.8.8 github.com aaaa

; <<>> DiG 9.18.42 <<>> @8.8.8.8 github.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26887
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;github.com.                    IN      AAAA

;; AUTHORITY SECTION:
github.com.             1112    IN      SOA     dns1.p08.nsone.net. hostmaster.nsone.net. 1656468023 43200 7200 1209600 3600

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Feb 04 05:54:38 GMT 2026
;; MSG SIZE  rcvd: 104

Is there any possibility to IPv6 support incorporated into the upgrade process so that "Prefer to use IPv4 even if IPv6 available" is not required in the future to perform an upgrade. Just to put things into context IPv6 traffic arriving at google.com peaked at 49.57% so far this year, it was 46.43% in January 2025. https://www.google.com/intl/en/ipv6/statistics.html

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.