I forgot to add IPv6 support to https://status.bsd.cafe - it's now active.
Thanks, @lw for the heads up!
If you want to make sure that a lot of small e-mail servers (like mine) will not reach your e-mail server, because you really hate us folks trying to keep e-mail decentralised, just use the CSS blocklist by #Spamhaus. This will greatly reduce your exposure to the even weirder small admins (like me) that try to use #IPv6. Throw in UCEPROTECTL3 by #Mailreach blocklist too to exclude us running our small, well-maintained mail servers at ISPs on small VPS or dedicated servers. #SarcasmButOnlyHalf
Guess, I spoilered something for #BoxyBSD now.
#illumos #solaris #opensolaris
@kp
Related... what has been discussed to date regarding dhclient #IPv6 in base?
@tuxpowered @antranigv
Sharing some technical details about how I'm setting up the hosted email service. It will not be a service of BSD Cafe but tied to my own business. It will run entirely on BSD systems and on bare metal, NOT on "cloud" VPS. It will use FreeBSD jails or OpenBSD or NetBSD VMs (but on bhyve, on a leased server - I do not want user data to be stored on disks managed by others). The services (opensmtpd and rspamd, dovecot, redis, mysql, etc.) will run on separate jails/VMs, so compromising one service will NOT put the others at risk. Emails will be stored on encrypted ZFS datasets - so all emails are encrypted at rest - and only dovecot will have access to the mail datasets. I'm also considering the possibility of encrypting individual emails with the user's login password - but I still have to thoroughly test this. The setup will be fully redundant (double mx for SMTP, a domain for external IMAP access that will be managed through smart DNS - which will distribute the connections on the DNS side and, in case of a server down, will stop resolving its IP, sending all the connections to the other. Obviously, everything will be accessible in both ipv4 and ipv6 and in two different European countries, on two different providers. Synchronization will occur through dovecot's native sync (extremely stable and tested). All technical choices will be clearly explained - the goal of this service is to provide maximum transparency to users on how things will be handled.
#BSD #FreeBSD #OpenBSD #NetBSD #emailHosting #encryption #ZFS #dovecot #opensmtpd #rspamd #emailSecurity #techTransparency #ipv6 #Europe
As I couldn't sleep, I wrote this script to generate local IPv6 unicast network addresses. It can be helpful for tests.
VMware/VSphere hosted in a datacenter, no other hardware exposed to us. Just ESXi hosts, VSAN, and virtual switches.
So, the idiot who had my job before me? Created four /24 networks internally. Source and/or destination NAT, and VPN services spread across SEVEN routers at the network edge. All connected with a house of cards mess of static routes.
Oh, and no consistency in VPNs, sometimes they are wireguard, sometimes they are IPSEC, and *shudders* sometimes they are L2TP. OPNSense, PFSense, and Mikrotik CHR VMs all present.
I added one new virtual router that isn't trash and started folding services over to it. As of Friday, the total is down to three routers, and I've reduced our public IPv4 usage by 80% so far. No, this provider does not provide #IPv6. My department's plan for this DC is to stop using it eventually, so I won't have to care.
Every single new webservice was a new public IP because the former ID10T didn't understand reverse proxies apparently.
This is the fuckwad who tried to have me fired four times before he himself was fired. He said I was incompetent and he couldn't work with me. Well, he was right about one thing, his horrendous attitude made him impossible to work with.
I'm slowly but surely deconstructing his messes. he's been gone for nearly a year now, and the company keeps paying for his awfulness.
next time on nuintari rants: How the shitass didn't understand Q-in-Q and now nuintari has to unfuck the world's most insane NNI.
Cross-post on Mastodon.
Question on configuring IPv6 SIT tunnels under new Ubiquity USG hardware:
https://www.reddit.com/r/Ubiquiti/comments/1b3428k/comment/kspn4li/?context=3
@gyptazy I tried to migrate home network to #IPv6 until I traveled to #Finland : the #WiFi guest and my mobile operator were stuck on #IPv4. I cannot connect to my home server through #WireGuard (IPv6 only).
Then I re-enabled dual stack when I came back home 😅
My issue was not caused by a Finnish issue, except about WiFi connection. The root cause is that mobile operator provides only IPv4 on roaming.
Sure, technically everything works fine on operating systems like #FreeBSD, #OpenBSD, #Debian, #Fedora etc. and all my monitoring, backup and admin infrastructure is #IPv6 only for years. But dealing with clients is something different. I think most clients already support #DualStack, especially within my circle but it could still be annoying for people that are forced to use #IPv4 only.
Sure, technically everything works fine on operating systems like #FreeBSD, #OpenBSD, #Debian, #Fedora etc. and all my monitoring, backup and admin infrastructure is #IPv6 only for years. But dealing with clients is something different. I think most clients already support #DualStack, especially within my circle but it could still be annoying for people that are forced to use #IPv4 only.
#ipv6 (default)
better late than never
RUT2_R_00.07.06 | 2023.12.20
New
Network
"Enabled IPv6 by default for mobile interfaces"
I checked it, it's true! (after factory reset - dualstack 👏)
https://wiki.teltonika-networks.com/view/RUT240_Firmware_Downloads#RUT2_R_00.07.06.3_.7C_2024.01.17
By the way. They still maintain/improve old devices.
Zdá se, že rok 2032 bude rokem #IPv6 na desktopu.
Czech Republic sets end date for IPv4 to June 2032. (Current adoption per Google IPv6 stats: ~26%.)
holy shit it's working!
After some more #ipv6 shenanigans:
Setup:
- TV is IPv4-only, in a discrete, dual stack "IoTrash" VLAN for all of the "smart" devices
- The "sending" devices (laptop, phone) in a single stack IPv6-only network, with DNS64 deployed and Tayga for NAT64
- Chromecast working between separate, dual stack networks, but it was still broken for IPv6-only clients (the ones with the media) to IPv4-only receivers (the ones displaying the media)
The key pieces I was missing were mdns forwarding for IPv6, as well as then adjusting Tayga's config so that it actually does NAT64 for internal RFC1918 ranges.
For mDNS:
The mdns-repeater plugin for opnsense is apparently IPv4-only (https://github.com/geekman/mdns-repeater/issues/3). There is a more general "UDP broadcast relay" project that you can use on opnsense, but that also is still IPv4-only. Avahi is, however, available for FreeBSD, and it will do both v4 and v6 just fine. There is no packaged plugin for opnsense, but you can install it just fine through the shell and configure it for IPv4 as well as IPv6 mDNS forwarding. The one piece that probably is important here is the reflect-ipv bool flag, which will basically do address family translation for you if needed (e.g. forwarding on IPv6 mDNS as IPv4 on the destination network).
So, now we can hear about Chromecast devices, but we can't get media flowing yet.
The next bit tripped me up in Tayga config. I was not aware of this part of the spec at this point, as I'd not yet implemented something where it's been relevant. But, if you use a well-known NAT64 prefix like 64:ff9b::/96, RFC 6052 indicates that the translator MUST NOT perform translation for RFC1918 destination address (Section 3.1), with more information about how this is to be implemented in mixed v4/6 environments to permit direct shortcuts for internal addresses, bypassing translators if feasible. Tayga honours this, so will not translate RFC1918 destination addresses when using the well-known 64:ff9b::/96 prefix.
SO!
After getting Avahi installed to actually forward on mDNS for IPv6, and changing Tayga's NAT64 prefix to a different global prefix, we have success!
Great success this evening! And then blerghness.
Finally managed to get enough holes poked in between VLANs to be able to segment the TV off properly in the IoTrash VLAN while still supporting chromecast and Airplay.
...but still only to be foiled again by the damn TV still being v4-only. So, it can be segmented off just fine in a dual stack network, and we can reach it from a more trusted dual stack network, but since it's stuck being v4-only it doesn't fly trying to reach it from the testing single stack dns64/nat64 network.
Maybe there is a way to still make that fly? But both Chromecast and Airplay, as far as I can see it, basically have the "sending" device (the one that holds the media) trigger the "receiving" device (the one displaying the media) to "call back" to it. We can "find" the v4-only TV from the single stack v6 network using mDNS tricks, but at least off the bat the v4-only TV isn't going to have a way to connect back to the "sending" v6-only device.
I mean, the v6-only device reaches the v4-only device through the NAT64 layer, and that's effectively a SNAT layer. I don't really see a way for a device on the "v4" side of the NAT64 (Tayga) to somehow "hit" Tayga effectively unsolicited from a network perspective to pass traffic to the v6 node "through" the NAT64 layer...unless the Tayga dynamic v4 pool mapping for v6 hosts is fully fixed for a given IPv6 client for the duration of the mapping (the same IPv4 address from the Tayga pool remains mapped to the same IPv6 client) regardless of flow (source/dest port, destination IP address) and permits unsolicited responses back from the v4 side?
In which case we would need to...do something like translating the IP addresses in some of the mDNS payload? Or something?
Brain fried...more battles later.
ok, #Ipv6 isn't easy
host www.netplus.co.in ns2.netplus.co.in
Using domain server:
Name: ns2.netplus.co.in
Address: 103.41.23.195#53
Aliases:
www.netplus.co.in has address 103.41.23.212
www.netplus.co.in has IPv6 address 64:ff9b::6729:17d4
🤦
Graph of the day: % #IPv6 of reading hours on my website, split out by day of the week. There used to be a substantial weekend effect (because many enterprises Don't Do IPv6), but it is not very pronounced anymore. I suspect a lot of "work time" internet traffic is no longer happening over office networks.
Today's best tweet on x.
#ipv6
My shirt just arrived... You'll probably easily find me :)
#fos #foss #opensource #buildinpublic #dev #development #coding #linux #freebsd #ipv6 #netbsd #openbsd #bsdcafe #bsdnetwork #debian #gardenlinux #lightningtalk #techtalk
#ipv6
quote:
Ondrej Filip
@ondrejfilip
3h
Big news! Yesterday, the Czech government approved a resolution that on June 6, 2032 (20 years after so called IPv6 launch day), it will end the provision of government services over IPv4. 👏 Who is gonna join us?
Jan 18, 2024 · 7:33 AM UTC
The EU stats are little bit outdated. Germany, France are ~70% (google stats)
https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=de,fr,be
Also the server side made progress. My last test with the first 100000 of the tranco list showed 26% IPv6. (28% including the wrong configured cdn , explanation here: https://gitlab.com/miyurusankalpa/IPv6-dns-server ) (corrected the figures, a lot of website have more than one A/AAAA record, after filtering the multiple answers .)
#datacenter #DC #SysOps #NetOps #IPv6
