3 ms·

The main complaint I have against IPv6 is the addresses are so unwieldy. When I look at them I have the same reaction as when I look at some kind of complex sc

The main complaint I have against IPv6 is the addresses are so unwieldy. When I look at them I have the same reaction as when I look at some kind of complex scientific formula comprised of operators and symbols that are unfamiliar. It also takes extra mental effort to expand the compressed zeros and interpret what I'm viewing. Even after reading about them many times and using them in (an albeit limited) fashion, they still just don't feel human friendly. Not like the more straightforward IPv4 addresses do. (Or even like a hypothetical "IPv5" that simply prefixes one extra octet). Whenever I bring this up I'm told something like "Don't bother memorizing IPv6 addresses. Use DNS instead."[1] That take completely overlooks the fact that if the numbers exist, you will inevitably wind up needing to deal with them at various points along the way. Eg. Debugging logs, sniffing network traffic, ruling out if DNS is down, etc. I'm a big fan of ergonomics to make things intuitive and reduce unnccessary cognitive overhead, and the new scheme is a regression in that regard. If anyone has tips on how they became more fluent with IPv6 I'd love to hear. [1] https://www.networkworld.com/article/934784/mission-impossible-memorizing-ipv6-addresses.html https://www.networkworld.com/article/934784/mission-impossib...

rkagerer 7mo ago
This is without even getting into learning the new (old?) paradigm of "exposing" all addresses to the whole internet. I realize "NAT" is not equivalent to "firewall", but placing them at the same boundary made things simple to understand conceptually. I for one never had trouble opening/forwarding ports (and liked the control it provided over what goes in and out, especially in the days before it all just became HTTP) but I sympathize with the major headaches the NAT "workaround" caused.
- lunar_rover 7mo ago
  NAT also solves the dynamic address issue. With GUA I need to deal with both dynamic prefix and randomised suffix that can be changed by seemingly unrelated things when opening ports to the internet.
  - preisschild 7mo ago
    Does your ISP not offer static prefixes? For 5€/mo additional I get a static /32 v4 (for NAT64) and a /60 v6 prefix.
  - _bernd 7mo ago
    That's why server use a static suffix and do slaac to get their prefix. It's really as simple as that. Regarding firewall policies: just because most network OS are plain dumb, does not implies that's the fault of IPv6. A zone based firewall solves that already. And for instance OpenWrt fw4 can make rules for suffixes in a zone too.
Dagger2 7mo ago
Just use it. This reaction is coming from a lack of familiarity, not from it actually being hard. Here's some roughly equivalent IP addresses: 203.0.113.45+192.168.1.1 ↔ 2001:db8:2d4f:1::1 203.0.113.45+192.168.1.2 ↔ 2001:db8:2d4f:1::2 203.0.113.45+192.168.1.3 ↔ 2001:db8:2d4f:1::3 203.0.113.45+192.168.2.1 ↔ 2001:db8:2d4f:2::1 The v6 addresses are made up of the network prefix (2001:db8:2d4f, basically an opaque string like 203.0.113.45+192.168), then the subnet ID (1, 2) and then the host ID on the network (1-3 and 1). When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.
- rkagerer 7mo ago
  Thanks, that's a helpful comparison. You've shown a fixed prefix 3 hextets (48 bits) in length - is that the most common convention these days? And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
  - Dagger2 7mo ago
    The most common is more like /56, which is unfortunate because it means you have to deal with "2001:db8:2d4f:61XX::". It's still easy enough to read the subnet out of :6101:, :6102:, :6103: etc, but it does mean every address is longer :( > And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned? Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them. I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too. Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.

rkagerer 7mo ago

This is without even getting into learning the new (old?) paradigm of "exposing" all addresses to the whole internet. I realize "NAT" is not equivalent to "firewall", but placing them at the same boundary made things simple to understand conceptually. I for one never had trouble opening/forwarding ports (and liked the control it provided over what goes in and out, especially in the days before it all just became HTTP) but I sympathize with the major headaches the NAT "workaround" caused.

lunar_rover 7mo ago
NAT also solves the dynamic address issue. With GUA I need to deal with both dynamic prefix and randomised suffix that can be changed by seemingly unrelated things when opening ports to the internet.
- preisschild 7mo ago
  Does your ISP not offer static prefixes? For 5€/mo additional I get a static /32 v4 (for NAT64) and a /60 v6 prefix.
- _bernd 7mo ago
  That's why server use a static suffix and do slaac to get their prefix. It's really as simple as that. Regarding firewall policies: just because most network OS are plain dumb, does not implies that's the fault of IPv6. A zone based firewall solves that already. And for instance OpenWrt fw4 can make rules for suffixes in a zone too.

Dagger2 7mo ago

Just use it. This reaction is coming from a lack of familiarity, not from it actually being hard. Here's some roughly equivalent IP addresses: 203.0.113.45+192.168.1.1 ↔ 2001:db8:2d4f:1::1 203.0.113.45+192.168.1.2 ↔ 2001:db8:2d4f:1::2 203.0.113.45+192.168.1.3 ↔ 2001:db8:2d4f:1::3 203.0.113.45+192.168.2.1 ↔ 2001:db8:2d4f:2::1 The v6 addresses are made up of the network prefix (2001:db8:2d4f, basically an opaque string like 203.0.113.45+192.168), then the subnet ID (1, 2) and then the host ID on the network (1-3 and 1). When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.

rkagerer 7mo ago
Thanks, that's a helpful comparison. You've shown a fixed prefix 3 hextets (48 bits) in length - is that the most common convention these days? And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
- Dagger2 7mo ago
  The most common is more like /56, which is unfortunate because it means you have to deal with "2001:db8:2d4f:61XX::". It's still easy enough to read the subnet out of :6101:, :6102:, :6103: etc, but it does mean every address is longer :( > And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned? Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them. I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too. Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.