Dagger2

21 ms·

211.
by Dagger2 9mo ago
No they didn't? v6 is compatible with v4 in tons of different ways, probably in almost every way that it's possible to be compatible with v4. Admittedly, it's not compatible in the ways that _aren't_ possible. But it&#x2
212.
by Dagger2 9mo ago
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator. There's g
213.
by Dagger2 9mo ago
That's not the case at all. You could disable their NAT and they wouldn't lose any protection whatsoever.
214.
by Dagger2 9mo ago
Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do tha
215.
by Dagger2 9mo ago
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it
216.
by Dagger2 9mo ago
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on. (Just to double-check... have you tried DHCPv6-PD? ISPs will
217.
by Dagger2 9mo ago
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the
218.
by Dagger2 9mo ago
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forward
219.
by Dagger2 9mo ago
That's kind of my point though: it didn't need to be written to expect a v6 upgrade, because the socket API is family-agnostic. 20 years ago, getaddrinfo() was 7 years old. You should have been using it already by then.
220.
by Dagger2 9mo ago
I get all of that... but it just sounds like you're arguing that either using RFC1918, or someone's inability to route to your router, is a firewall. Neither of these things are NAT! Nor will either of them protect you from all in
221.
by Dagger2 9mo ago
> ignore (effectively: drop) Well, no. They do ignore them, but that's not effectively a drop. It's an ignore. It just means that they don't edit the packet. Whether it gets dropped or not depends completely on the routing
222.
by Dagger2 9mo ago
I'd be tempted to shove that VPN into a network namespace together with jool, and NAT64 their 10.x subnets into, let's say, 2001:db8:a:b::/96, so that their 10.1.2.3 becomes 2001:db8:a:b::10.1.2.3. Then there's no overla
223.
by Dagger2 9mo ago
It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension. How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4
224.
by Dagger2 9mo ago
Make sure they actually have GUA addresses, not just link-locals. If you're on a Linux machine, check `ip -c addr show` for an address that's "scope global" and doesn't start with "f". Those are the ones y
225.
by Dagger2 9mo ago
I'd expect folks would see the behavior you're describing here as being part of security. However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not
226.
by Dagger2 9mo ago
> How do you get to github? $ wget https://github.com/ Resolving github.com (github.com)... 64:ff9b::8c52:7204, 140.82.114.4 Connecting to github.com (github.com)|64:ff9b::8c52:7204|:443... connected. HTTP reques
227.
by Dagger2 9mo ago
But we do want a v6-only future, right? We don't want to be running both protocols forever, which is what you'd be asking for.
228.
by Dagger2 9mo ago
They didn't screw up. They made it a breaking change to OSs because it had to be a breaking change to OSs. If anyone screwed up here, it was the people who made v4, not the ones that made v6. For ping, I think it originally had differe
229.
by Dagger2 9mo ago
Google's stats are tracking the percentage of people that reach Google over IPv6. That means they've not just been given addresses, but they configured them and are actively using them. How can that possibly not count as "ado
230.
by Dagger2 9mo ago
No, that would be forwards compatibility. v4 doesn't have forwards compatibility with any address protocol that uses addresses bigger than 32 bits, and it never will regardless of how that protocol is designed because the flaw is in
231.
by Dagger2 9mo ago
You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to b
232.
by Dagger2 9mo ago
They pretty much did. "Just add N bits to v4" is far more work than you're thinking it is, and most of what v6 does is a direct consequence of taking v4 and adding more bits to it. The amount of work doesn't depend on th
233.
by Dagger2 9mo ago
Dual stack is a natural part of migrating between two protocols, because it's the most compatible way of handling both of them. You don't need to use dual stack to use both v4 and v6, but you'll probably choose to the instant
234.
by Dagger2 9mo ago
I suspect you forgot to implement a workaround for servers with broken pMTUd. The quickest test for that is probably to run `ip link set mtu 1280 dev eth0` on a client machine and see if it helps. You'll encounter the same problem on v
235.
by Dagger2 9mo ago
An ASN with a /32 allocation (the smallest for ISPs) is four billion /64s. It takes dozens of yottabytes of traffic to exhaustively scan one single /64. The entire v4 space takes 0.00000001 yottabytes, or about 110 GB/po
236.
by Dagger2 9mo ago
No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP. It doesn't filter incoming traffic. If it did then you might have a point, but since it doesn't it&#
237.
by Dagger2 9mo ago
APNIC's stats check for that. For the US, it makes the difference between 58.74% capable and 57.85% preferring, so it doesn't produce a huge discrepancy.
238.
by Dagger2 9mo ago
That would only happen if all of v6's growth is coming from mobile users, no mobile networks are growing/deployed without v6, and also no users are dropping their wired connections. You can look at the AS breakdowns on APNIC'
239.
by Dagger2 9mo ago
These are all the same address too: 1.2.3.4, 16909060, 0x1020304, 0100401404, 1.131844, 1.0x20304, 1.0401404, 1.2.772, 1.2.0x304, 1.2.01404, 1.2.3.0x4, 1.2.0x3.4, 1.2.0x3.0x4, 1.0x2.772, 1.0x2.0x304, 1.0x2.01404, 1.0x2.3.4, 1.0x2.3.0x4, 1
240.
by Dagger2 9mo ago
We aren't. There's a variety of reasons people choose to use v4 (some good, some bad), but you don't have to. The network my desktop is on doesn't use v4. It works. v4 isn't a required dependency.

More ›