Live data from Hacker News

Why IPv6 is so complicated

github.com

251–260 of 519 posts

Re: Why IPv6 is so complicated

#251
post #53

My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce. Fast forward 15 years snd the situation has improved quite dramatically. IPv6 has some quirks that make it harder to digest. - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space - privacy extensions:…

The nice thing about NAT is it makes the security model easier to reason about. By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe. I really do think IPv6 missed a tr…

> The nice thing about NAT is it makes the security model easier to reason about.

I first heard that relying on the 'moated castle' design of security (firewalls) was bad idea and no longer best practice a decade or two ago, and while inside/outside may be a convenient mental shortcut for security, it shouldn't be relied about.

Sure, sensible people know that NAT ≠ security, but by having private/public IPs I think it makes people's thinking lazy. Every system having publicly routable addresses (but not publicly accessible, due to SPI) would force more folks to actually examine their security controls.

It's too easy to think "ah, this has a 10.x.y.z address, therefore it's inside and safe". No, because most attacks nowadays involve compromised/ing clients, and then running around 10.x networks where people got lazy because these things are on the "inside".

Re: Why IPv6 is so complicated

#252

Earlier quoted context omitted.

Can you say more about the ISP connecting to any computer on your network? I can’t find any references to this aspect in googling the right terms and the concept is foreign to me. There are a bunch of ways to break it, or misconfigure it. But I have idea what this isp method is.

It's just normal routing. If you send packets to a router, it'll route them. More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via ` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them. Anyone on your imme…

Have you tried that?

I have yet to see a router that allows that forwarding unless explicitly configured. Still, i'm using mostly openwrt/opnsense/mikrotik

Default is to disallow/block forwarding packets from public wan to private range lan.

ISP can still inject packets on ports that NAT opens if it spoofs the source address/port, so you still have some validity to argument.

Re: Why IPv6 is so complicated

#253

Earlier quoted context omitted.

What would that "thing" be?

See RFC 2766.

Ah, right, that one with all the ALGs. Kinda NAT64's ancestor, though I have no idea of the evolution/development process.

I don't believe this ever worked at scale, even if it is pretty much NAT64. Particularly the part where IPv4 hosts can reach IPv6 systems with the NAT-PT tracking through DNS what is given out in A records is "a bit much".

Re: Why IPv6 is so complicated

#254
post #191
post #168

My problem with IPv6 is that I can't double click 2001:db8::1428:57ab to select the entire address. It's a silly complaint but representative of real ergonomic issues.

It would be pretty straightforward to change the text selection rule, so that double-clicking anything matching the syntax of an IPv6 address selects the whole address. The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?

This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing.

"A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that.

Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.

Re: Why IPv6 is so complicated

#255
I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.

Re: Why IPv6 is so complicated

#256

Earlier quoted context omitted.

You don't need any tricks like that. Regular new connections will work.

No it won't because that's not how NAT is working.

It will, and if you test it then it does.

NAT doesn't apply to inbound connections if you don't have a matching port forward rule, so it kind of doesn't matter how NAT works here. This is pure routing, not NAT.

Re: Why IPv6 is so complicated

#257

I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.

It basically did, just in hex...

Re: Why IPv6 is so complicated

#258

Earlier quoted context omitted.

It's just normal routing. If you send packets to a router, it'll route them. More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via ` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them. Anyone on your imme…

Have you tried that? I have yet to see a router that allows that forwarding unless explicitly configured. Still, i'm using mostly openwrt/opnsense/mikrotik Default is to disallow/block forwarding packets from public wan to private range lan. ISP can still inject packets on ports that NAT opens if it spoofs the source address/port, so you still have some validity to argument.

Yup, repeatedly.

It's true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.

Re: Why IPv6 is so complicated

#259

Earlier quoted context omitted.

Have you tried that? I have yet to see a router that allows that forwarding unless explicitly configured. Still, i'm using mostly openwrt/opnsense/mikrotik Default is to disallow/block forwarding packets from public wan to private range lan. ISP can still inject packets on ports that NAT opens if it spoofs the source address/port, so you still have some validity to argument.

Yup, repeatedly. It's true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.

> Yup, repeatedly

Cool, me too :)

Anyway, the other side of the argument:

It is the default and default is secure. Users don't have to reason about it, they can assume it works, how doesn't matter and they may lack training/willingness to figure out.

You can't say the same for IPv6 where default is allow (have things changed?, havent checked in a long time)

Re: Why IPv6 is so complicated

#260

Earlier quoted context omitted.

Yup, repeatedly. It's true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.

> Yup, repeatedly Cool, me too :) Anyway, the other side of the argument: It is the default and default is secure. Users don't have to reason about it, they can assume it works, how doesn't matter and they may lack training/willingness to figure out. You can't say the same for IPv6 where default is allow (have things changed?, havent checked in a long time)

Of course you can say the same for v6. Blocking connections that go from WAN to LAN by default has the same effect on both protocol families. If you assume that having the appropriate firewall rule to do that is the default then inbound connections will also be blocked on v6 by default.

NAT contributes nothing to your security in this scenario, and instead makes it harder (not easier) to understand and reason about what your router is doing.

Post reply on HN