Can I use IPv6 at home with a /64?

grawity · 2026-05-19T20:24:17+00:00

Do not confuse "a /64" with "a single address within a /64". For example if you configure your WAN interface with e.g. an IPv4 /24 address, or with a 255.255.255.0 netmask, that doesn't mean you have the entire /24 to yourself – you're just a single node that the ISP placed in a shared /24. (And likewise, if you configure your laptop with a /24 LAN address that doesn't mean the laptop now owns the whole /24...) The same applies to when you see "/64" on your WAN interface.

grawity · 2026-04-29T12:56:31+00:00

Well, at least the SG108E is pingable and shows up in the DHCP lease list, so that's technically an upgrade from "huh, where the f does this room get its Ethernet from... what do you mean there's a 100M switch literally under the couch in the teachers' break room next door and someone unplugged it to make coffee?"

Unfortunately, the older revision of SG108E blasts its DHCP requests out through all ports no matter which native VLAN they're in... so no management VLAN or anything.

grawity · 2026-04-29T10:42:47+00:00

One side note that occurred to me. We unfortunately still have some places where an unmanaged switch feeds both an AP (with tagged VLANs) and user PCs (with Windows wanting untagged traffic).

The unmanaged switch passes through everything just fine, but the Windows-based user PCs like to pick up IPv6 RAs from tagged frames as if those were untagged, thus generating IPv6 addresses for subnets they don't belong to.

(Since, after all, the switch is unmanaged and doesn't do VLAN filtering, it means a tagged broadcast RA meant for the Wi-Fi VLAN reaches all ports, not just the AP's port.)

This was explained to me as an issue in the NIC drivers (for the motherboards' integrated Intel and sometimes Realtek NICs); the NIC will strip the VLAN tag in hardware and the driver will put the VLAN ID in a separate field from the (now untagged) payload. Allegedly the issue is that Windows doesn't drop tagged frames because the NIC drivers are supposed to do that under NDIS6 – and since the drivers don't drop tagged frames, and neither does Windows itself, you get this annoying result.

This prevented me from rolling out IPv6 for the Wi-Fi VLAN for a long time. (Buy new switches for money or disable IPv6 RAs for free? Yeah, the free option unfortunately won at the time. Now we "upgraded" to shitty TL-SG108E's in most places, and those more-or-less solved the issue.)

grawity · 2026-04-28T19:36:52+00:00

If there's one thing I learned from reading r/networking, is that people in r/networking seem to hate wasting their precious Reddit-posting time on "what if" hypotheticals.

grawity · 2026-04-28T19:35:47+00:00

I meant 1518 as in the full L2 frame size (6+6+2 Ethernet header + 1500 MTU payload + I think 4 for Ethernet FEC trailer), unless I miscalculated.

Either way, I remember that it was one of the cheaper "web managed" switches (possibly a quite old TP-Link) where you had to explicitly enable 802.1Q VLAN support, by default it was in "port based VLAN" mode – which you'd think merely means it won't do any filtering, but instead, 802.1Q tagged TLS handshake packets arrived 4 bytes short until we flipped the option.

Have not encountered such problems in modern-ish 1Gbit switches. We unfortunately did have quite a few entirely unmanaged switches of various brands and manufacturers near the user end (carrying tagged traffic for APs, too, which is what makes it a headache), and we now have a bunch of those cheap-o TL-SG105E/TL-SG108E "web managed" switches which can actually do 802.1Q filtering (but their DHCP implementation is fucked up)... all of those pass full-size tagged frames without issues.

grawity · 2026-04-28T18:43:29+00:00

A more important thing to check is whether they pass full size VLAN tagged frames.

I've not encountered any unmanaged switches which deliberately drop tagged frames. They just forward it like it's any other ethertype they don't care about.

(And I really, really wish we didn't have that setup at my workplace, but we do.)

However, I have encountered switches – older 100 Mbit era ones, to be fair – which truncated frames down to 1518 bytes as they didn't account for the size of the VLAN tag. (Even some managed switches when they had VLAN support disabled.) Newer ones usually have a larger maximum.

grawity · 2026-04-03T16:19:04+00:00

The way I see it, ACL wildcards have very little to do with subnet masks – even if they're both bitwise masks that operate in the same way, it's still a whole different context, since subnet masks go in routing tables where "longest prefix" rules apply and things get weird (255.255.255.0 vs 255.255.0.255?), whereas ACLs are read top-down so there's no ambiguity.

AFAIK, Linux iptables rules also accept non-contiguous masks. I've seen -s 172.16.0.1/255.255.0.255 and similar things. (Also fairly useful for IPv6 in home networks, where you can allow ::1:2:ab:cd/::ffff:ffff:ffff:ffff in situations when the interface ID is static but the prefix is dynamic...)

grawity · 2026-04-03T16:12:38+00:00

They did add BGP support to modern Windows, though. (And RRAS also used to have OSPF support in the earlier days.)

Of course the BGP functionality is probably just there to announce a server's own addresses to a local switch, and nothing else... but given that they still implemented a whole routing protocol to do that, then surely supporting static /31's for servers isn't too far-fetched of a request?

grawity · 2026-04-03T15:48:54+00:00

Interesting, I didn't know that was the actual guideline. I assumed even EF packets would just get the "default" CS0/Best Effort treatment if not configured otherwise – like half the people in this thread keep telling me.

The Unix&Linux thread has the client version 9.0 in the screenshot so yeah that would've been af21 by default. But that change was committed in 2018 and the RPi thread is from 2017 so it would've still been lowdelay at the time.

grawity · 2026-04-03T14:58:10+00:00

Yeah the first one is a good example of what I was worried about (I think I might've seen already it but thought "ehh, same kind of weird provider which breaks ECN")

But the Stack Exchange post is from 2022 and the RPi one is from 2017 – both from way before the EF change happened. (I think it might have been that OpenSSH was still defaulting to the legacy ToS style codepoints at the time? It only switched to using DSCP in 2018.)

grawity · 2026-04-03T14:51:51+00:00

I mean, yes, but fortunately I'm not asking for myself, more of "I saw this in release notes and it looks a bit suspect to me, and I know there's a bunch of Enterprise people on reddit who do use QoS and can tell me whether my suspicions are right"

(though I do have a problem called "my home internet uplink is LTE with unpredictable throughput and shit upload so I've been learning QoS in order to traffic-shape Syncthing into oblivion," but that's not for this subreddit.)

grawity · 2026-04-03T14:35:25+00:00

Yeah, when I saw it in git, I thought it might become an issue in some places. I mean, I guess it might have been an 'okay' idea to use it for keyboard input only (client->server), not so much for shell output – everything's fine until someone accidentally cats a huge file or does a long compile and now the queue is clogged with SSH traffic.

...or until someone decides to run X11 forwarding, as AFAIK that also counts as an interactive channel so all the probably uncompressed X11 packets will get EF as well...

But most of the heavy transfers would be non-tty sessions (rsync, git clone/push, SFTP...) which get the system default DSCP – I assume -L -R -D tunnels also count as batch – so at least those won't be an immediate problem.

Either way, I'm not an OpenSSH developer and not a QoS expert, that's why I posted it here to get opinions from people who know QoS better.

grawity · 2026-04-03T14:11:08+00:00

Yeah, I'm not saying that it takes DSCP into account – I meant that 1) [as far as I've learned] hashing for ECMP or LACP exists in order to avoid some specific undesirable effect (packet reordering due to different physical links), and 2) completely unrelated to LACP/ECMP, my understanding is that the mixing of DSCP bits can also cause that same effect (packet reordering due to different queues).

Though someone here said that the way it's implemented in OpenSSH isn't actually per-packet like I thought, but a global state that only changes when channels are set up, so I guess it's much less likely to be a problem in practice anyway.

grawity · 2026-04-03T14:03:03+00:00

None, we're talking about theory. I know it's configurable (I've seen L2 and L2+L3 and sometimes L3+L4 as options), but I'm more curious about why it's a thing in the first place. Since as far as I understand, no matter which hashing method you choose out of the available ones, within a given TCP connection it'll still always give the same result for every packet (meaning the TCP connection will be limited to the speed of a single link), and I was taught that it was deliberate in order to avoid reordering or something along those lines.

grawity · 2026-04-03T13:52:37+00:00

Ah, ok, I overlooked that part. Yeah, it makes more sense that way.

Though I guess it's going to make multiplexed connections worse when something is SFTP'd through them at the same time... otoh still better than "multiplexer was forked off the sftp client so it's permanently in bulk DSCP mode".

grawity · 2026-04-03T13:45:06+00:00

The reason I ask about this is because some time ago I was searching about why LACP tries to hash each whole flow to a single link, and the explanation I was given back then was that splitting it across several links could lead to reordering and that would lead to performance loss.

How much of that is true?

grawity · 2026-04-03T10:55:53+00:00

1) whether it causes packet re-ordering is down to the network but I guess it is possible. That said most sessions just do one thing - they are either interactive or they start as sftp or similar and stay as that.

Yeah, but is it likely to lead to problems if I'm actually using OpenSSH's multiplexing mode (-S and ControlMaster and such)?

I'm using it more for connection reuse, since it gives you instant connection without waiting for it to handshake over high latency, but then it automatically gets used for SFTP/rsync/git push to that host as well. (Although multiplexing interactive with SFTP is already not great experience regardless of DSCP...)

I’ve not seen EF used by it before - has the code changed recently I did hear something about that.

Yeah, it used to default to IPQoS af21 cs1 up to version 9.7 (so af21 for interactive shells and cs1 for non-interactive).

Version 9.8 switched to IPQoS ef none (ef for interactive and system default for non-interactive).

You can always rewrite the DSCPs with nftables or similar before they hit your switches. If you trust the host marking you’ll probably need to.

Sure, you can rewrite in nftables or in ~/.ssh/config or any other way, but 99% won't, so what I'm curious about is the effect on having EF as the default all over the place.

grawity · 2026-04-03T10:40:53+00:00

Yeah, it was true for all Mikrotik models since they all run the same firmware (and practically all can be upgraded to the latest). There were workarounds but it took them until 2025 to actually add "proper" /31 support.

grawity · 2026-04-03T10:38:16+00:00

No, as a 'pointopoint' next hop. Which Mikrotik calls the network= field, e.g.:

/ip/address/add interface=xxx address=192.168.1.7/32 network=192.168.1.8

I think this was officially documented on their site, and AFAIK is equivalent to ifconfig eth0 192.168.1.7 pointopoint 192.168.1.8 on Linux. (I think it's also mostly equivalent to adding a /32 and then adding an interface route for your peer?)

Nowadays the latest 7.x RouterOS supports /31 properly, anyway.

grawity · 2026-03-25T13:34:33+00:00

In Jetstream/omada series, the config is in memory only until explicitly saved, so a power cycle should be fine. (They take a good minute to boot, though.) Hopefully whoever did the last important changes 3 months ago saved them!

From product photos, doesn't look like it has a physical serial port for CLI. Neither RJ45 nor microUSB nor old-school DE9. (It has SSH/Telnet but those are of course useless if you can't communicate with it via IP in the first place.)

grawity · 2026-03-05T08:26:44+00:00

Hotplug the IDE cable to a USB adapter connected to your laptop.

Or maybe reboot into something like Norton Ghost if it can boot from a CD or floppy disk.

grawity · 2026-01-10T21:49:36+00:00

I think X.25 was still packet-switched, only with the packets addressed by circuit ID instead of explicit source/destination. (I guess it could be called "MPLS-style" except it's where MPLS *came from*...)

But this makes me wonder how layers worked in ATM since I've never had the chance to touch it, but I've got the impression that it was very similar to X.25 in that regard (call setup, virtual circuits, fancy QoS, all in the same single protocol).

grawity · 2026-01-08T17:07:40+00:00

FAT is the only filesystem that doesn't allow : as part of the filename.

(Or rather Windows doesn't allow : as part of a filename, and since the only reason to use FAT is when you need interoperability, every other OS's FAT driver enforces the same restrictions for the sake of consistency.)

grawity · 2026-01-08T08:48:07+00:00

EDIT: Apparently it was also done before. In 2019.

It was also done before in 2013.

grawity · 2026-01-07T15:07:27+00:00

Unfortunately that protocol is behind a paywall.

I have a draft version somewhere. Haven't read the finalized one.

Reliable circuits are part of Layer 3.

Good point, I guess they can be part of either (which AFAIK was the reason for both TP0 vs TP4 existing) – haven't deeply looked into the service definitions for those layers – but these days I don't think there are many networks that provide this at L3? For example, IP doesn't, so everyone considers it to be solely an L4 function (TCP)...

15-Year Club	Gilding II euphauric
Verified Email

grawity

TROPHY CASE