The only legitimate v6 prefix smaller than /64 is /127, to be used for point to point links, similar to /31’s in v4, but these aren’t processed for routing outside of the boxes the link is configured on.
The concepts of addressing for v4 and v6 don’t map 1:1.
From the perspective of the internet, and any properly configured routing infrastructure, they should only ever be interested in the first 64 bits when routing, the second 64 should be exclusively the domain of the last segment. It’s like inserting an additional type of addressing between the routing portion and the protocol port.
You kind of have this with v4, but it’s variable, particularly since CIDR shot the v4 address classes in the head, so the equipment had to be able to process the entire address with every routing lookup and other functions.
From the perspective of the internet, and any properly configured routing infrastructure, they should only ever be interested in the first 64 bits when routing, the second 64 should be exclusively the domain of the last segment.
Interesting. But routers don’t actually strip that, do they? So the endpoint I’m communicating with will still get the full /128 address? I’m concerned about the privacy implications of MAC addresses being sent to everybody and their mother.
The full 128 bits of source and destination addresses are passed end-to-end, my comment is specifically focused on routing.
As far as privacy is concerned, v6 allows a much broader scope for protection than v4 and NAT, as the IA portion (second 64 bits) can be changed at will by that endpoint. EUI-64 is still common with basic v6 stacks, but SLAAC will rotate every ~24 hours.
EDIT: I’d conflated the original SLAAC specification with the SLAAC privacy extensions RFC 4941, which at almost 2 decades old itself could be argued to be the canonical reference.
One of my favourite features of v6 is it explicitly permits, and caters for, multiple addresses on an interface. This means you could theoretically have a unique address per application, within multiple prefixes if they’re available.
I personally have all my internal services accessible only on addresses under ULA prefixes, which intrinsically prevents them from being accessed outside of my network, no firewall required. Using WireGuard permits remote access when needed.
As far as privacy is concerned, v6 allows a much broader scope for protection than v4 and NAT, as the IA portion (second 64 bits) can be changed at will by that endpoint. EUI-64 is still common with basic v6 stacks, but SLAAC will rotate every ~24 hours.
Oh that’s cool.
One of my favourite features of v6 is it explicitly permits, and caters for, multiple addresses on an interface. This means you could theoretically have a unique address per application, within multiple prefixes if they’re available.
Couldn’t you do that with v4? Or maybe that was only with bridge interfaces. hmm
I personally have all my internal services accessible only on addresses under ULA prefixes, which intrinsically prevents them from being accessed outside of my network, no firewall required. Using WireGuard permits remote access when needed.
This is… interesting. At first I thought it was just like the v4 loopback range, but like you mentioned it opens up the possibility of routing between two on-machine networks. I’m gonna have to digest that idea for a while.
What’s a useful way to manage clients identities? Like before, static MAC would allow the assignment of a static IP, then that device could be handled by the firewall using that IP. But with these random addresses is there any way to use targeted firewalling/monitoring for specific devices?
One of my favourite features of v6 is it explicitly permits, and caters for, multiple addresses on an interface. This means you could theoretically have a unique address per application, within multiple prefixes if they’re available.
Couldn’t you do that with v4? Or maybe that was only with bridge interfaces. hmm
Multiple v4 addresses are possible, like secondary/virtual configurations, but it’s not a concept built into the formal specifications, and usually constrained to advanced networking equipment.
With v6, multiple addresses, across multiple prefixes, are first class features in even the dumbest nodes. I honestly consider it one of the most valuable features of v6.
I personally have all my internal services accessible only on addresses under ULA prefixes, which intrinsically prevents them from being accessed outside of my network, no firewall required. Using WireGuard permits remote access when needed.
This is… interesting. At first I thought it was just like the v4 loopback range, but like you mentioned it opens up the possibility of routing between two on-machine networks. I’m gonna have to digest that idea for a while.
ULA prefixes are basically equivalent to RFC1918 v4 private ranges. I have a unique ULA prefix wherever I have a RFC1918 range. Again, the key feature is they exist alongside GUA (public) prefixes, not instead of them. The key is the routing stack explicitly constrains reachability to within your administrative domain.
What’s a useful way to manage clients identities? Like before, static MAC would allow the assignment of a static IP, then that device could be handled by the firewall using that IP. But with these random addresses is there any way to use targeted firewalling/monitoring for specific devices?
The way you’re supposed to identify hosts for v6 configuration is with a DUID instead of a MAC. That said, I don’t consider it necessary to keep track of individual hosts except for servers or other requirements for static addresses.
A better way of managing it is to group common hosts within a specific /64, and set policy specific to that. The hosts can then cycle through IADs as normal. It’s why it’s so important for ISPs to provide a minimum of /60 or /56 via PD as a default.
The only exception is if you need historical tracking of host activity, but any environment in that position is already heavily infected with surveillance urchins.
The way you’re supposed to identify hosts for v6 configuration is with a DUID instead of a MAC.
So this is just a feature of DHCPv6, right? The one unsupported by Android?
A better way of managing it is to group common hosts within a specific /64, and set policy specific to that. The hosts can then cycle through IADs as normal. It’s why it’s so important for ISPs to provide a minimum of /60 or /56 via PD as a default.
Then, without some kind of ident, you need physical separation or VLANs which gets kind of annoying in a small/home network. Mostly I want to keep an eye on windows machines, silence consumer devices (IoT/entertainment devices), and allow some services for a couple of servers (don’t tell my ISP). They all need to be treated uniquely by the router/firewall.
SLAAC won’t work with a smaller subnet. Static addressing is not an option since your /64 is going to be dynamically assigned. That leaves DHCPv6, which won’t work with any android devices or chromebooks.
It would be best to just run IPv6 on one network if you can’t at least get a /60.
I’m a bit concerned about SLAAC’s metadata leakage. Sending out many of my devices’ MAC addresses to the world isn’t exactly the best for privacy. My key devices like laptop and phone use MAC randomization, but I have a ton of other stuff that doesn’t.
That leaves DHCPv6, which won’t work with any android devices or chromebooks.
Damn, that’s a straight WONTFIX, too since 2014. Lots of religious argument in there, maybe I’m reading all that tonight.
Modern operating systems don’t use the MAC address for SLAAC. They generate a completely random address. You can choose a stable address or a temporary one that will change frequently for more privacy. You can also use both, IPv6 allows multiple addresses on one device.
You can’t subnet below a /64 at all? Or it just makes things like SLAAC/auto-addressing using the MAC address unusable?
The only legitimate v6 prefix smaller than /64 is /127, to be used for point to point links, similar to /31’s in v4, but these aren’t processed for routing outside of the boxes the link is configured on.
The concepts of addressing for v4 and v6 don’t map 1:1.
From the perspective of the internet, and any properly configured routing infrastructure, they should only ever be interested in the first 64 bits when routing, the second 64 should be exclusively the domain of the last segment. It’s like inserting an additional type of addressing between the routing portion and the protocol port.
You kind of have this with v4, but it’s variable, particularly since CIDR shot the v4 address classes in the head, so the equipment had to be able to process the entire address with every routing lookup and other functions.
Interesting. But routers don’t actually strip that, do they? So the endpoint I’m communicating with will still get the full /128 address? I’m concerned about the privacy implications of MAC addresses being sent to everybody and their mother.
The full 128 bits of source and destination addresses are passed end-to-end, my comment is specifically focused on routing.
As far as privacy is concerned, v6 allows a much broader scope for protection than v4 and NAT, as the IA portion (second 64 bits) can be changed at will by that endpoint. EUI-64 is still common with basic v6 stacks, but SLAAC will rotate every ~24 hours.
EDIT: I’d conflated the original SLAAC specification with the SLAAC privacy extensions RFC 4941, which at almost 2 decades old itself could be argued to be the canonical reference.
One of my favourite features of v6 is it explicitly permits, and caters for, multiple addresses on an interface. This means you could theoretically have a unique address per application, within multiple prefixes if they’re available.
I personally have all my internal services accessible only on addresses under ULA prefixes, which intrinsically prevents them from being accessed outside of my network, no firewall required. Using WireGuard permits remote access when needed.
Oh that’s cool.
Couldn’t you do that with v4? Or maybe that was only with bridge interfaces. hmm
This is… interesting. At first I thought it was just like the v4 loopback range, but like you mentioned it opens up the possibility of routing between two on-machine networks. I’m gonna have to digest that idea for a while.
What’s a useful way to manage clients identities? Like before, static MAC would allow the assignment of a static IP, then that device could be handled by the firewall using that IP. But with these random addresses is there any way to use targeted firewalling/monitoring for specific devices?
Multiple v4 addresses are possible, like secondary/virtual configurations, but it’s not a concept built into the formal specifications, and usually constrained to advanced networking equipment.
With v6, multiple addresses, across multiple prefixes, are first class features in even the dumbest nodes. I honestly consider it one of the most valuable features of v6.
ULA prefixes are basically equivalent to RFC1918 v4 private ranges. I have a unique ULA prefix wherever I have a RFC1918 range. Again, the key feature is they exist alongside GUA (public) prefixes, not instead of them. The key is the routing stack explicitly constrains reachability to within your administrative domain.
The way you’re supposed to identify hosts for v6 configuration is with a DUID instead of a MAC. That said, I don’t consider it necessary to keep track of individual hosts except for servers or other requirements for static addresses.
A better way of managing it is to group common hosts within a specific /64, and set policy specific to that. The hosts can then cycle through IADs as normal. It’s why it’s so important for ISPs to provide a minimum of /60 or /56 via PD as a default.
The only exception is if you need historical tracking of host activity, but any environment in that position is already heavily infected with surveillance urchins.
So this is just a feature of DHCPv6, right? The one unsupported by Android?
Then, without some kind of ident, you need physical separation or VLANs which gets kind of annoying in a small/home network. Mostly I want to keep an eye on windows machines, silence consumer devices (IoT/entertainment devices), and allow some services for a couple of servers (don’t tell my ISP). They all need to be treated uniquely by the router/firewall.
SLAAC won’t work with a smaller subnet. Static addressing is not an option since your /64 is going to be dynamically assigned. That leaves DHCPv6, which won’t work with any android devices or chromebooks.
It would be best to just run IPv6 on one network if you can’t at least get a /60.
I’m a bit concerned about SLAAC’s metadata leakage. Sending out many of my devices’ MAC addresses to the world isn’t exactly the best for privacy. My key devices like laptop and phone use MAC randomization, but I have a ton of other stuff that doesn’t.
Damn, that’s a straight WONTFIX, too since 2014. Lots of religious argument in there, maybe I’m reading all that tonight.
Thanks for answering my questions.
Modern operating systems don’t use the MAC address for SLAAC. They generate a completely random address. You can choose a stable address or a temporary one that will change frequently for more privacy. You can also use both, IPv6 allows multiple addresses on one device.
Great to know, thanks!