3 ms·

> IPv6 restores globally routable addresses to every node, letting peers connect without contortions. Global routeability doesn't automatically mean global rea

by lxgr 10mo ago

> IPv6 restores globally routable addresses to every node, letting peers connect without contortions. Global routeability doesn't automatically mean global reachability. Many consumer and professional routers will block inbound TCP connections, and incoming UDP traffic without at least similar outbound UDP traffic preceding it, so you will still need hole punching. Hole punching does get significantly more easy with v6, though, since there's really only one way to do "outbound connections only" firewalling (while there's several ways to port translate, some really hostile to hole punching). Arguably one thing that's missing is a very simple, implicit standard that allows signalling a willingness to accept an inbound TCP connection from a given IP/port that such stateful firewalls can honor, similar to how they already implicitly do it for UDP, but with HTTP 3 running over UDP, the point might well be moot soon.

Giefo6ah 10mo ago
That simple, implicit standard exists since RFC793: Simultaneous initiation is only slightly more complex, as is shown in figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED. TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED Simultaneous Connection Synchronization Figure 8. Every stateful firewall supports this. All you need to communicate off-band is IP addresses and ports.
- lxgr 10mo ago
  Huh, TIL, thank you! Are you sure all firewalls support this? RFC 5382 seems to specify it, but then again, middleboxes aren't exactly known for strict RFC compliance...
the8472 10mo ago
At least there's an explicit standard for signalling: RFC 6887 Port Control Protocol. Many routers also support it. But it's often disabled for the same reason as having router-level firewalls in the first place.
- ninkendo 10mo ago
  > But it's often disabled for the same reason as having router-level firewalls in the first place. Yeah, anything that allows hosts to signal that they want to accept connections, is likely the first thing a typical admin would want to turn off. It’s interesting because nowadays it’s egress that is the real worry. The first thing malware does is phone home to its CNC address and that connection is used to actually control nodes in a bot net. Ingress being disabled doesn’t really net you all that much nowadays when it comes to restricting malware. In an ideal world we’d have IPv6 in the 90’s and it would have been “normal” for firewalls to be things you have on your local machine, and not at the router level, and allowing ports is something the OS can prompt the user to do (similar to how Windows does it today with “do you want to allow this application to listen for connections” prompt.) But even if that were the case I’m sure we would have still added “block all ingress” as a best practice for firewalls along the way regardless.
  - forgotaccount3 10mo ago
    > Ingress being disabled doesn’t really net you all that much nowadays when it comes to restricting malware. But how much of this is because ingress is typically disabled so ingress attacks are less valuable relative to exploiting humans in the loop to install something that ends up using egress as part of it's function.
    - Dylan16807 10mo ago
      Since we're talking about programs that are trying to set up a connection no matter what, I'm going to say "not much". It's not significantly shrinking the attack surface and forcing attackers onto a plan B that's meaningfully harder to do. It just adds this layer of awkwardness to everything, and attackers shrug and adapt.
Denatonium 10mo ago
This is true, but the beauty of UDP is that it's basically just a raw socket with a tiny 8 byte header slapped on top, with 2 bytes for source port, 2 bytes for destination port, 2 bytes for length, and 2 bytes for a checksum. You could slap a UDP header on top of the TCP header and get the benefits of TCP with the hole-punching capabilities of UDP, provided you implemented some kind of keep-alive functionality and an out-of-band way of telling the "server" to establish an outbound connection with the "client". Or use QUIC, assuming it fits the use case.
TheusHen 10mo ago
Absolutely agreed — and this is an important distinction. IPv6 gives you global addressability, not guaranteed reachability. Stateful firewalls still exist and inbound-by-default is still rare on consumer networks. The I6P design explicitly assumes that reality. The motivation for being IPv6-first is not “firewalls disappear”, but that the problem space collapses from many forms of NAT and address/port translation down to mostly predictable stateful filtering. That’s also why the transport is QUIC/UDP: firewall behavior is far more consistent, hole punching is simpler, and path changes are survivable. So IPv6 isn’t treated as magic — it’s treated as a cleaner substrate with fewer pathological cases than IPv4 NAT.

by lxgr 10mo ago

Giefo6ah 10mo ago

That simple, implicit standard exists since RFC793: Simultaneous initiation is only slightly more complex, as is shown in figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED. TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED Simultaneous Connection Synchronization Figure 8. Every stateful firewall supports this. All you need to communicate off-band is IP addresses and ports.

lxgr 10mo ago
Huh, TIL, thank you! Are you sure all firewalls support this? RFC 5382 seems to specify it, but then again, middleboxes aren't exactly known for strict RFC compliance...

the8472 10mo ago

At least there's an explicit standard for signalling: RFC 6887 Port Control Protocol. Many routers also support it. But it's often disabled for the same reason as having router-level firewalls in the first place.

ninkendo 10mo ago
> But it's often disabled for the same reason as having router-level firewalls in the first place. Yeah, anything that allows hosts to signal that they want to accept connections, is likely the first thing a typical admin would want to turn off. It’s interesting because nowadays it’s egress that is the real worry. The first thing malware does is phone home to its CNC address and that connection is used to actually control nodes in a bot net. Ingress being disabled doesn’t really net you all that much nowadays when it comes to restricting malware. In an ideal world we’d have IPv6 in the 90’s and it would have been “normal” for firewalls to be things you have on your local machine, and not at the router level, and allowing ports is something the OS can prompt the user to do (similar to how Windows does it today with “do you want to allow this application to listen for connections” prompt.) But even if that were the case I’m sure we would have still added “block all ingress” as a best practice for firewalls along the way regardless.
- forgotaccount3 10mo ago
  > Ingress being disabled doesn’t really net you all that much nowadays when it comes to restricting malware. But how much of this is because ingress is typically disabled so ingress attacks are less valuable relative to exploiting humans in the loop to install something that ends up using egress as part of it's function.
  - Dylan16807 10mo ago
    Since we're talking about programs that are trying to set up a connection no matter what, I'm going to say "not much". It's not significantly shrinking the attack surface and forcing attackers onto a plan B that's meaningfully harder to do. It just adds this layer of awkwardness to everything, and attackers shrug and adapt.

Denatonium 10mo ago

This is true, but the beauty of UDP is that it's basically just a raw socket with a tiny 8 byte header slapped on top, with 2 bytes for source port, 2 bytes for destination port, 2 bytes for length, and 2 bytes for a checksum. You could slap a UDP header on top of the TCP header and get the benefits of TCP with the hole-punching capabilities of UDP, provided you implemented some kind of keep-alive functionality and an out-of-band way of telling the "server" to establish an outbound connection with the "client". Or use QUIC, assuming it fits the use case.

TheusHen 10mo ago

Absolutely agreed — and this is an important distinction. IPv6 gives you global addressability, not guaranteed reachability. Stateful firewalls still exist and inbound-by-default is still rare on consumer networks. The I6P design explicitly assumes that reality. The motivation for being IPv6-first is not “firewalls disappear”, but that the problem space collapses from many forms of NAT and address/port translation down to mostly predictable stateful filtering. That’s also why the transport is QUIC/UDP: firewall behavior is far more consistent, hole punching is simpler, and path changes are survivable. So IPv6 isn’t treated as magic — it’s treated as a cleaner substrate with fewer pathological cases than IPv4 NAT.