Prefixlen 64 through rc.conf doesn't work, but for reason doing it manually like this does. Also route addition through rc.conf returns and invalid argument error, but manually works. Perhaps somebody here can explain why, but I'm just happy to have it finally working
Geekbench 6 is a downloaded, pre-compiled Linux ELF binary:
bash-5.2# file geekbench6
geekbench6: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
bash-5.2#
Maybe there is a newer version of Geekbench than 6-1-0? I happened to have 6-1-0 handy.
What's up with the lines in the terminal output below that say >! [ 612604.8349775] linux_sys_rt_sigaction: setting signal 64 ignored? Maybe ignoring signal 64 is a safety feature in NetBSD Linux emulation? Seems like signal 64 is sometimes used in rootkits? Are people running Geekbench sometimes giving Geekbench root privileges even if they don't run Geekbench as root?
linveo# cd /use/pkgsrc/emulators/suse131_base
linveo# make && make install
[ . . . ]
linveo# modload compat_linux
linveo# echo $?
0
linveo# cd /emul/linux/bin
linveo# bash
bash-5.2# bash --version
GNU bash, version 5.2.37(1)-release (x86_64--netbsd)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
bash-5.2# cd /usr/pkgsrc/emulators/suse131_base/
bash-5.2# ls
CVS INSTALL MESSAGE.NetBSD distinfo
DEINSTALL MESSAGE.DragonFly Makefile files
DESCR MESSAGE.FreeBSD PLIST work
bash-5.2# ls ~
.bash_history .login Geekbench-6.1.0-Linux
.cshrc .profile Geekbench-6.1.0-Linux.tar.gz
.klogin .shrc motowashere
.lesshst .ssh plan9-environment-variables
bash-5.2# ls ~/Geekbench-6.1.0-Linux
geekbench-workload.plar geekbench6 geekbench_x86_64
geekbench.plar geekbench_avx2
bash-5.2# ls -l ~/Geekbench-6.1.0-Linux
total 488224
-rw-r--r-- 1 tom 1000 316570457 Jun 6 2023 geekbench-workload.plar
-rw-r--r-- 1 tom 1000 4295615 Jun 6 2023 geekbench.plar
-rwxr-xr-x 1 tom 1000 3468192 Jun 6 2023 geekbench6
-rwxr-xr-x 1 tom 1000 91511824 Jun 6 2023 geekbench_avx2
-rwxr-xr-x 1 tom 1000 83715032 Jun 6 2023 geekbench_x86_64
bash-5.2# ~/Geekbench-6.1.0-Linux/geekbench6
Geekbench 6.1.0 : https://www.geekbench.com/
Geekbench 6 requires an active internet connection and automatically uploads
benchmark results to the Geekbench Browser.
Upgrade to Geekbench 6 Pro to enable offline use and unlock other features:
https://store.primatelabs.com/v6
Enter your Geekbench 6 Pro license using the following command line:
/root/Geekbench-6.1.0-Linux/geekbench6 --unlock <email> <key>
System Information
Operating System openSUSE Leap 15.5 Alpha
Kernel Linux 6.3.10 x86_64
Model N/A
Motherboard N/A
CPU Information
Name AMD Ryzen 9 7950X
Topology 1 Processor, 1 Core, 2 Threads
Identifier AuthenticAMD Family 25 Model 97 Stepping 2
Base Frequency 4.49 GHz
L1 Instruction Cache 32.0 KB
L1 Data Cache 32.0 KB
L2 Cache 1.00 MB
L3 Cache 64.0 MB
Memory Information
Size 4.00 GB
Single-Core
Running File Compression
Running Navigation
Running HTML5 Browser
Running PDF Renderer
Running Photo Library
Running Clang
Running Text Processing
[ 612426.8340863] linux_sys_rt_sigaction: setting signal 64 ignored
Running Asset Compression
Running Object Detection
Running Background Blur
Running Horizon Detection
Running Object Remover
Running HDR
Running Photo Filter
Running Ray Tracer
Running Structure from Motion
Multi-Core
Running File Compression
Running Navigation
Running HTML5 Browser
Running PDF Renderer
Running Photo Library
Running Clang
Running Text Processing
[ 612604.8349775] linux_sys_rt_sigaction: setting signal 64 ignored
Running Asset Compression
Running Object Detection
Running Background Blur
Running Horizon Detection
Running Object Remover
Running HDR
Running Photo Filter
Running Ray Tracer
Running Structure from Motion
Uploading results to the Geekbench Browser. This could take a minute or two
depending on the speed of your internet connection.
Upload succeeded. Visit the following link and view your results online:
https://browser.geekbench.com/v6/cpu/9018149
Visit the following link and add this result to your profile:
https://browser.geekbench.com/v6/cpu/9018149/claim?key=903037
bash-5.2#
Wanted to post that I had some very unique router requirements, and ended up installing OPNSense on some hardware I put together and it not only worked out of the box, it pushes 10gbps pixies with ease on hardware sub 60w. Was a bear to configure though.
@ZizzyDizzyMC said:
Wanted to post that I had some very unique router requirements, and ended up installing OPNSense on some hardware I put together and it not only worked out of the box, it pushes 10gbps pixies with ease on hardware sub 60w. Was a bear to configure though.
That's the BSD power right there! What kind of hardware configuration you have if I may ask?
@ZizzyDizzyMC said:
Wanted to post that I had some very unique router requirements, and ended up installing OPNSense on some hardware I put together and it not only worked out of the box, it pushes 10gbps pixies with ease on hardware sub 60w. Was a bear to configure though.
That's the BSD power right there! What kind of hardware configuration you have if I may ask?
I'm using a box from Riverside Networks that was bricked, I opened it up reflashed the nvram chip and put on stock intel bios for the Xeon D cpu onboard. It has a Xeon D-1553N (8c16t) and 32GB of ram, quad 10g and 8 1g, but only 2 10g and 6 1g ports are usable due to the hardware design of the board using a multiplier that seems to only be supported by Riverside's custom distro stuff.
Definitely would never recommend Riverside's equipment due to how locked down it is, but used it can be made into something cool if you know your way around hardware.
@yoursunny It's a nice offer to share your ASN, thank you, but maybe you are just trolling. How can I know that you are not trolling?
We are the Official Troll so you can never tell.
When IPv6 is delivered via a BGP session, it is guaranteed to be a routed subnet instead of an on-link subnet.
Routed subnets have fewer problems than on-link subnets as you don't need to answer Neighbor Solicitations.
How is Official Troll status working for you? How will others' "never being able to tell" help you long term?
What I hope for, for you, instead of Official Troll status, would be to see you holding a wonderful reputation as helpful, friendly, and kind. And also as a fundamental contributor to the larger internet community. Like Rich Stevens: Guru of the Unix gurus. I want to see the US Congress and the President give you a standing ovation on the occasion of their granting you honorary full citizenship. But that's just what I want. You should do what you want.
When IPv6 is delivered via a BGP session, it is guaranteed to be a routed subnet instead of an on-link subnet.
Routed subnets have fewer problems than on-link subnets as you don't need to answer Neighbor Solicitations.
Thanks @yoursunny! Now I remember your ndpresponder which you told me about and which I used previously to get IPv6 working. I appreciate your patience in telling me a second time! Probably only 42 more times will be required!
So, @Crab, it looks like @yoursunny is kindly hinting that your issue with IPv6 and FreeBSD rc.conf not working but configuring rc.local working might be caused by rc.conf expecting but not receiving NDP responses.
@Not_Oles said:
So, @Crab, it looks like @yoursunny is kindly hinting that your issue with IPv6 and FreeBSD rc.conf not working but configuring rc.local working might be caused by rc.conf expecting but not receiving NDP responses.
Wireshark is your friend.
Wireshark solves confirms or denies all networking problems.
@Not_Oles said:
So, @Crab, it looks like @yoursunny is kindly hinting that your issue with IPv6 and FreeBSD rc.conf not working but configuring rc.local working might be caused by rc.conf expecting but not receiving NDP responses.
After reading through the latest comments, I went back and checked what I actually did to make it work and I realized my initial post about this was incorrect.
According to Kimsufi, only /128 is assigned to you. This means that you have 'neighbors' very close to you and according to our resident expert, @yoursunny, you have to deal with 'Neighbor Solicitations'.
The IPv6 configuration for my box is this:
inet6 2607:5300:1234:1234::1 prefixlen 128
and I said that adding the same thing with prefix length 64 from rc.conf didn't work but worked when you manually issued the command. Well, I was actually wrong with this statement and what I actually did was created a /64 for the same interface:
inet6 2607:5300:1234:12ff::1 prefixlen 64
As you can see the last 1234 is 12FF instead which now means that the neighbors and not anymore close by and if I interpret @yoursunny's comment 'Routed subnets have fewer problems' properly, that's exactly what is happening here.
Once /64 setting was added, creating a route for it didn't throw an error like it did when I just had /128:
When I was trying to get this work initially, I was asking Co-Pilot some advice for different possible configuration options. I asked it now why this type of config is needed, and this is what it responded:
In FreeBSD, when you assign an IPv6 address with a prefix length of /128 (like 2607:5300:1234:1234::1/128),
it means that this address is a single, specific address with no additional addresses in the same subnet.
This can sometimes cause issues with routing and connectivity because there's no room for a subnet prefix.
By adding a /64 address range (like 2607:5300:1234:12ff::1/64), you're defining a larger subnet that includes
your specific address. This helps with routing and ensures that your interface can communicate properly
within the network.
IPv6 addresses are divided into two parts: the network prefix and the interface identifier. When you use
a /128 prefix, you're saying that all 128 bits of the address are used to identify a single device. This
leaves no bits to define a network range or to address other devices within the same subnet. Essentially,
it’s like having a street address without naming the street—it’s too specific to form a neighborhood.
Here's a quick analogy:
/128 Prefix: This is like having a precise address like "123 Main St, Apartment 456." This address points
to a single apartment in a building, with no other addresses.
/64 Prefix: This is more like "Main St." This allows for many houses or buildings to be part of "Main St,"
defining a range of addresses within that street.
In networking terms, having a /64 prefix is standard practice for IPv6 because it allows for a vast number
of individual device addresses (2^64 addresses) within the same subnet. This facilitates proper routing
and communication between devices on the same network.
Thus, assigning a /64 address to your interface helps the network to understand that it’s part of a larger
subnet, making routing and communication smoother.
TL;DR
My last post was incorrect. You need to set up /128 AND /64 AND route on /64 to make it work:
I've not delved into IPv6 before (no need) so above was interesting. Analogous to IPv4 /32 & /24 methinks.
(Though I still don't get the convention of calling them a prefix, when they're often expressed as a suffix.)
it looks like the server gets two IPv6 addresses, one from each invocation of ifconfig. The second line gives a single address (a /128 from a /64). The first line gives another single /128 address which, with respect to the /64 from the second line, is out-of-band because 1234:: is not part of 12ff::.
I guess that the router at 12ff:ff:ff:ff:ff might be configured to forward from and to send to 1234::1. Maybe the router neither accepts from nor sends to 12ff::1. Or maybe the 12ff::1 is used by your server both when packets from 1234::1 are sent to and when packets are received from 12ff:ff:ff:ff:ff.
I am not sure whether anything I am saying here is correct. It amazes me how complex the subject of networking seems.
At the least, it is delightful that you got IPv6 working with FreeBSD on your server! Congrats!
Are you assigned both 1234::1 and 12ff::1? If not, what happens if other VMs on that node use the same 12ff::1? Shouldn't that be at least an address that is guaranteed to be unique?
@cmeerw said:
Are you assigned both 1234::1 and 12ff::1? If not, what happens if other VMs on that node use the same 12ff::1? Shouldn't that be at least an address that is guaranteed to be unique?
Very good question! @Not_Oles is wondering about the same thing. 1234::1 is /64 which could easily be assigned instead of /128, but 12ff::1 is /56!
This is a dedicated, so there's no other tenant on the same box, but your question is still valid. If I have 1234::1, is there another person in OVH with 1235::1?
After posting the last message I tried bunch of different variations of this but nothing else works. Either you get 'No buffer space available' error while pinging, or 'Invalid argument' for just trying to set the route, or 'No route to host'. The /56 interface of 2607:5300:1234:12ff::1 also becomes pingable from outside network, so perhaps OVH is assigning /56 after all.
Hopefully somebody more knowledgeable (@yoursunny) can explain this. The strangest thing is that this works just fine with /128 address and provided gateway in Linux, but FreeBSD is refusing to accept them in the first place (invalid argument)!
@Crab said: The strangest thing is that this works just fine with /128 address and provided gateway in Linux, but FreeBSD is refusing to accept them in the first place (invalid argument)!
I think Linux only gets around this by letting you add a "random" host route on the network interface that you can then use for your default gateway.
On thing you could do on the BSDs is to use the link-local address of the gateway for your default route (although that has the disadvantage that the link-local address might change when the gateway device is replaced)
Otherwise, widening the network to a /56 (and making sure not to assign IPv6 addresses outside your assigned network to your local machine) might be the best option.
There's no 'hijacking' of 1234:12ff anymore and potentially being a bad neighbor. The commands also make more sense than my previous attempts. I still believe they allow you to use full /64 even with Kimsufi line despite them assigning /128 up front, but that's another story completely.
It still won't work through rc.conf though, but I'll take this.
My Linveo NetBSD-current VPS now seems to have a new routed IPv6/64 and a new routed IPv6/48, both from HE TunnelBroker.Net.
By the way, last I looked, HE TunnelBroker seemed unwilling to continue assigning tunnels to Hetzner servers. Maybe Kimsufi servers also might seem blocked at TunnelBroker?
In other news, I invested yesterday afternoon looking at possibly getting tshark going. Pkgsrc doesn't directly offer tshark. I thought maybe compiling pkgsrc's Wireshark just might give me tshark, and pkgsrc does offer Wireshark (net/wireshark). But pkgsrc's Wireshark needs X installed or else the compile errors out:
ERROR: wireshark-4.4.1nb2 uses X11, but /usr/X11R7 not found
Options for me now seem to include at least:
Install X,
Compile tshark from Wireshark sources in /usr/local,
Try termshark, which is in /usr.pkgsrc/wip/termshark, but might require X
Check what's in plan9port, which already is installed,
Hi @yoursunny! Thanks for helping! May I please ask what are the reasons why you suggest Wireshark for me rather than tshark or something else intended for the command line? Are there specific, important things that Wireshark will do and that no command line tool will do? Thanks again!
Hi @yoursunny! Thanks for helping! May I please ask what are the reasons why you suggest Wireshark for me rather than tshark or something else intended for the command line? Are there specific, important things that Wireshark will do and that no command line tool will do? Thanks again!
Wireshark is easier to use than Tshark, because you can filter packets, expand sections, etc.
These two applications have the same functionality otherwise, but different user experience.
We generally recommend Wireshark for human operator and use Tshark for scripting.
@yoursunny said: Wireshark is easier to use than Tshark, because you can filter packets, expand sections, etc.
Thanks! To make sure I understand, are you saying that Tshark will not filter packets and will not expand sections? Besides filtering packets and expanding sections, is there anything else which might be especially important in the "etc?" Thanks again!
Just for fun I might go ahead and try to compile and install X on my Linveo NetBSD-current VPS. With X installed, probably compiling Wireshark out of /usr/pkgsrc/net/wireshark might work. Also I want to find out whether compiling and installing Wireshark silently gives me Tshark. Wireshark uses cmake, and I haven't messed much with cmake yet. I haven't messed much with X.
Comments
@yoursunny
I hope everyone gets the servers they want!
I was finally able to get it working with this in rc.local:
/sbin/ifconfig igb0 inet6 <ipv6_address> prefixlen 64/sbin/route -6 add default -ifp igb0 <ipv6_gw_address>Prefixlen 64 through rc.conf doesn't work, but for reason doing it manually like this does. Also route addition through rc.conf returns and invalid argument error, but manually works. Perhaps somebody here can explain why, but I'm just happy to have it finally working
Congrats!
Why?
Why?
I hope everyone gets the servers they want!
Seems like NetBSD's Linux emulation can run Geekbench 6!
Geekbench 6 scores for our nice Linveo 2 vCore Ryzen 9 7950X NetBSD/Linux VPS:
Check https://browser.geekbench.com/v6/cpu/9018149 if you want to see the full test result.
Geekbench 6 is a downloaded, pre-compiled Linux ELF binary:
Maybe there is a newer version of Geekbench than 6-1-0? I happened to have 6-1-0 handy.
What's up with the lines in the terminal output below that say
>! [ 612604.8349775] linux_sys_rt_sigaction: setting signal 64 ignored? Maybe ignoring signal 64 is a safety feature in NetBSD Linux emulation? Seems like signal 64 is sometimes used in rootkits? Are people running Geekbench sometimes giving Geekbench root privileges even if they don't run Geekbench as root?Thanks @Linveo!
I hope everyone gets the servers they want!
Rent our ASN and IPv6 magically starts to work.
Both BIRD and Pathvector support FreeBSD.
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
Do we have a list of LES providers who are offering BSD VPS options?
VPS providers to check out:
@yoursunny It's a nice offer to share your ASN, thank you, but maybe you are just trolling. How can I know that you are not trolling?
I hope everyone gets the servers they want!
@Not_Oles my friend you're having way too much fun with your NetBSD!
Wanted to post that I had some very unique router requirements, and ended up installing OPNSense on some hardware I put together and it not only worked out of the box, it pushes 10gbps pixies with ease on hardware sub 60w. Was a bear to configure though.
That's the BSD power right there! What kind of hardware configuration you have if I may ask?
I'm using a box from Riverside Networks that was bricked, I opened it up reflashed the nvram chip and put on stock intel bios for the Xeon D cpu onboard. It has a Xeon D-1553N (8c16t) and 32GB of ram, quad 10g and 8 1g, but only 2 10g and 6 1g ports are usable due to the hardware design of the board using a multiplier that seems to only be supported by Riverside's custom distro stuff.
Definitely would never recommend Riverside's equipment due to how locked down it is, but used it can be made into something cool if you know your way around hardware.
We are the Official Troll so you can never tell.
When IPv6 is delivered via a BGP session, it is guaranteed to be a routed subnet instead of an on-link subnet.
Routed subnets have fewer problems than on-link subnets as you don't need to answer Neighbor Solicitations.
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
How is Official Troll status working for you? How will others' "never being able to tell" help you long term?
What I hope for, for you, instead of Official Troll status, would be to see you holding a wonderful reputation as helpful, friendly, and kind. And also as a fundamental contributor to the larger internet community. Like Rich Stevens: Guru of the Unix gurus. I want to see the US Congress and the President give you a standing ovation on the occasion of their granting you honorary full citizenship. But that's just what I want. You should do what you want.
Thanks @yoursunny! Now I remember your ndpresponder which you told me about and which I used previously to get IPv6 working. I appreciate your patience in telling me a second time!
Probably only 42 more times will be required! 
So, @Crab, it looks like @yoursunny is kindly hinting that your issue with IPv6 and FreeBSD rc.conf not working but configuring rc.local working might be caused by rc.conf expecting but not receiving NDP responses.
Thanks again, @yoursunny!
I hope everyone gets the servers they want!
Wireshark is your friend.
Wireshark solves confirms or denies all networking problems.
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
After reading through the latest comments, I went back and checked what I actually did to make it work and I realized my initial post about this was incorrect.
According to Kimsufi, only /128 is assigned to you. This means that you have 'neighbors' very close to you and according to our resident expert, @yoursunny, you have to deal with 'Neighbor Solicitations'.
The IPv6 configuration for my box is this:
inet6 2607:5300:1234:1234::1 prefixlen 128and I said that adding the same thing with prefix length 64 from rc.conf didn't work but worked when you manually issued the command. Well, I was actually wrong with this statement and what I actually did was created a /64 for the same interface:
inet6 2607:5300:1234:12ff::1 prefixlen 64As you can see the last 1234 is 12FF instead which now means that the neighbors and not anymore close by and if I interpret @yoursunny's comment 'Routed subnets have fewer problems' properly, that's exactly what is happening here.
Once /64 setting was added, creating a route for it didn't throw an error like it did when I just had /128:
/sbin/route -6 add default -ifp igb0 2607:5300:1234:12ff:ff:ff:ff:ffAfter this everything started to work!
When I was trying to get this work initially, I was asking Co-Pilot some advice for different possible configuration options. I asked it now why this type of config is needed, and this is what it responded:
In FreeBSD, when you assign an IPv6 address with a prefix length of /128 (like 2607:5300:1234:1234::1/128),
it means that this address is a single, specific address with no additional addresses in the same subnet.
This can sometimes cause issues with routing and connectivity because there's no room for a subnet prefix.
By adding a /64 address range (like 2607:5300:1234:12ff::1/64), you're defining a larger subnet that includes
your specific address. This helps with routing and ensures that your interface can communicate properly
within the network.
IPv6 addresses are divided into two parts: the network prefix and the interface identifier. When you use
a /128 prefix, you're saying that all 128 bits of the address are used to identify a single device. This
leaves no bits to define a network range or to address other devices within the same subnet. Essentially,
it’s like having a street address without naming the street—it’s too specific to form a neighborhood.
Here's a quick analogy:
/128 Prefix: This is like having a precise address like "123 Main St, Apartment 456." This address points
to a single apartment in a building, with no other addresses.
/64 Prefix: This is more like "Main St." This allows for many houses or buildings to be part of "Main St,"
defining a range of addresses within that street.
In networking terms, having a /64 prefix is standard practice for IPv6 because it allows for a vast number
of individual device addresses (2^64 addresses) within the same subnet. This facilitates proper routing
and communication between devices on the same network.
Thus, assigning a /64 address to your interface helps the network to understand that it’s part of a larger
subnet, making routing and communication smoother.
TL;DR
My last post was incorrect. You need to set up /128 AND /64 AND route on /64 to make it work:
/sbin/ifconfig igb0 inet6 2607:5300:1234:1234::1 prefixlen 128/sbin/ifconfig igb0 inet6 2607:5300:1234:12ff::1 prefixlen 64/sbin/route -6 add default -ifp igb0 2607:5300:1234:12ff:ff:ff:ff:ffI've not delved into IPv6 before (no need) so above was interesting. Analogous to IPv4 /32 & /24 methinks.
(Though I still don't get the convention of calling them a prefix, when they're often expressed as a suffix.)
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
Hi @Crab!
Wow! Thanks!
I have to confess not understanding most of what you just posted. From the last part,
it looks like the server gets two IPv6 addresses, one from each invocation of
ifconfig. The second line gives a single address (a /128 from a /64). The first line gives another single /128 address which, with respect to the /64 from the second line, is out-of-band because 1234:: is not part of 12ff::.I guess that the router at 12ff:ff:ff:ff:ff might be configured to forward from and to send to 1234::1. Maybe the router neither accepts from nor sends to 12ff::1. Or maybe the 12ff::1 is used by your server both when packets from 1234::1 are sent to and when packets are received from 12ff:ff:ff:ff:ff.
I am not sure whether anything I am saying here is correct. It amazes me how complex the subject of networking seems.
At the least, it is delightful that you got IPv6 working with FreeBSD on your server!
Congrats! 
I hope everyone gets the servers they want!
Are you assigned both
1234::1and12ff::1? If not, what happens if other VMs on that node use the same12ff::1? Shouldn't that be at least an address that is guaranteed to be unique?Very good question! @Not_Oles is wondering about the same thing. 1234::1 is /64 which could easily be assigned instead of /128, but 12ff::1 is /56!
This is a dedicated, so there's no other tenant on the same box, but your question is still valid. If I have 1234::1, is there another person in OVH with 1235::1?
After posting the last message I tried bunch of different variations of this but nothing else works. Either you get 'No buffer space available' error while pinging, or 'Invalid argument' for just trying to set the route, or 'No route to host'. The /56 interface of 2607:5300:1234:12ff::1 also becomes pingable from outside network, so perhaps OVH is assigning /56 after all.
Hopefully somebody more knowledgeable (@yoursunny) can explain this. The strangest thing is that this works just fine with /128 address and provided gateway in Linux, but FreeBSD is refusing to accept them in the first place (invalid argument)!
I think Linux only gets around this by letting you add a "random" host route on the network interface that you can then use for your default gateway.
On thing you could do on the BSDs is to use the link-local address of the gateway for your default route (although that has the disadvantage that the link-local address might change when the gateway device is replaced)
Otherwise, widening the network to a /56 (and making sure not to assign IPv6 addresses outside your assigned network to your local machine) might be the best option.
All right, I think I finally got it! I was reading their guide one more time for clues and I came up with this syntax which works:
/sbin/ifconfig igb0 inet6 2607:5300:1234:1234::1 prefixlen 128/sbin/route -6 add 2607:5300:1234:12ff:ff:ff:ff:ff -iface igb0/sbin/route -6 add default 2607:5300:1234:12ff:ff:ff:ff:ffThere's no 'hijacking' of 1234:12ff anymore and potentially being a bad neighbor. The commands also make more sense than my previous attempts. I still believe they allow you to use full /64 even with Kimsufi line despite them assigning /128 up front, but that's another story completely.
It still won't work through rc.conf though, but I'll take this.
And on NetBSD the command to add that out-of-subnet host route would be:
EDIT: also need
-connectedGood morning!
My Linveo NetBSD-current VPS now seems to have a new routed IPv6/64 and a new routed IPv6/48, both from HE TunnelBroker.Net.
By the way, last I looked, HE TunnelBroker seemed unwilling to continue assigning tunnels to Hetzner servers. Maybe Kimsufi servers also might seem blocked at TunnelBroker?
In other news, I invested yesterday afternoon looking at possibly getting tshark going. Pkgsrc doesn't directly offer tshark. I thought maybe compiling pkgsrc's Wireshark just might give me tshark, and pkgsrc does offer Wireshark (net/wireshark). But pkgsrc's Wireshark needs X installed or else the compile errors out:
ERROR: wireshark-4.4.1nb2 uses X11, but /usr/X11R7 not foundOptions for me now seem to include at least:
tcpdump, which already is installed, andWhat do people think about Scapy?
Here's an HN discussion about Scapy from 2022: Scapy: Low level packet hacking toolkit for Python
What's the Plan 9 equivalent for tcpdump / tshark? Is it available in plan9port?
Thanks to @yoursunny for suggesting Wireshark! Thanks to @linveo for the nice VPS! Thanks to all of you guys here in the LES BSD thread! @Crab @FrankCastle Thanks to the NetBSD developers and to all LESbianz!
I hope everyone gets the servers they want!
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
Hi @yoursunny! Thanks for helping!
May I please ask what are the reasons why you suggest Wireshark for me rather than tshark or something else intended for the command line? Are there specific, important things that Wireshark will do and that no command line tool will do? Thanks again! 
I hope everyone gets the servers they want!
Wireshark is easier to use than Tshark, because you can filter packets, expand sections, etc.
These two applications have the same functionality otherwise, but different user experience.
We generally recommend Wireshark for human operator and use Tshark for scripting.
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
Thanks! To make sure I understand, are you saying that Tshark will not filter packets and will not expand sections? Besides filtering packets and expanding sections, is there anything else which might be especially important in the "etc?" Thanks again!
Just for fun I might go ahead and try to compile and install X on my Linveo NetBSD-current VPS. With X installed, probably compiling Wireshark out of /usr/pkgsrc/net/wireshark might work. Also I want to find out whether compiling and installing Wireshark silently gives me Tshark. Wireshark uses
cmake, and I haven't messed much withcmakeyet. I haven't messed much with X.I hope everyone gets the servers they want!