[ansible]

> These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable IPv6 rather than learning about all these small issues and working around them.

So that's me in a nutshell. I've read various things on IPv6 over the years, and I think I might even have the O'Reilly book laying around somewhere. I understand some of the basics, but I don't really "get" IPv6. I'm still at a bit of a loss on how my local network should be configured, and what services are needed for what.

Though I'm really at a loss as far as network security and firewalls go. I've been setting up firewalls with NAT for 20 years, but I'm still not sure how its all going to work with IPv6. In the mean time, I just disable all IPv6 stuff on the firewall machines, and try not to worry about it.

In the age of constant probes, a simple mistake can compromise our entire network, which sounds... unpleasant.

I suppose I'll just keep putting off learning about IPv6 until we get to the point where I can't order a cloud instance from our provider that comes with an IPv4 address.

[throw0101a]

> I've been setting up firewalls with NAT for 20 years, but I'm still not sure how its all going to work with IPv6.

The same way: tracking of state.

An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an outside packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in its table it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.

The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.

With IPv6 address/port rewriting is not done. Only state tables are altered and checked.

New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.

There's no magical security behind NAT: tuples and packet flags read, looked up in a state table, allowed or not depending on either firewall rule or state presence.

[zekica]

It took me a long time to finally "get" IPv6.

But as soon as you don't try to apply IPv4 conventions to IPv6, it really clicks: - RA packets don't have default gateway - default gateway is always on fe80:: and is the actual host that sent the RA - You can configure hosts via RA not to send packets directly to other hosts with the same prefix (instead sending them through the gateway) by disabling On-Link flag - You can use RA and DHCPv6 over any link, not just Ethernet

[goohle]

> default gateway is always on fe80::

In theory, we can reserve `169.254.1.1` as default gateway (and default DNS server) for IPv4, to get rid of DHCP protocol. I'm doing so in my embedded project for network connection via USB, because it makes network configuration static.

[themulticaster]

Just a heads up for anyone confused about 169.254.1.1: 169.254.0.0/16 is the link-local address block for IPv4, but link-local addressing is rarely used in IPv4. OTOH, the fe80::/10 address block on IPv6 is widely known since link-local addresses are mandated by the standard.

[Dagger2]

If you already know v4 then there's not much to learn. There are only really three differences:

a) You use a /64 from the subnet your upstream assigns you, instead of a /24 from RFC1918.

b) You don't use NAT.

c) You run an RA daemon on the router instead of a DHCP server.

Firewalling is exactly the same as in v4 -- you block inbound connections and permit outbound connections by default. A firewall without NAT is no different to a firewall with NAT (since NAT only helps with address space exhaustion and contributes nothing to securing the network).

One advantage of v6 is that you don't receive constant probes. Any v4 address will see a steady stream of them, but that's not true on v6. (v6 is so big that randomly scanning addresses in the hopes that they're assigned to something that will respond is unviable.)

You'll get v6 just fine if you spend some time using it on a real network.

[curryst]

> Though I'm really at a loss as far as network security and firewalls go. I've been setting up firewalls with NAT for 20 years, but I'm still not sure how its all going to work with IPv6. In the mean time, I just disable all IPv6 stuff on the firewall machines, and try not to worry about it.

Hopefully you've heard this before, and I'm sorry if I'm beating a dead horse, but NAT is not a firewall. It does render hosts behind the NAT not connectable from the Internet by default, but that's because they're unroutable not a security feature.

I.e. there was a bug a while ago that let people send UPnP requests over WAN to your router, which makes your hosts suddenly routable. NAT won't stop that from happening and your hosts are basically internet-accessible. A firewall configured to only allow outbound connections would have stopped that.

So if you consider NAT a routing feature, it works the same it always did. You configure the firewall to only allow outbound connections, unless you have a specific reason to allow inbound connections. I don't actually know if it's less secure. NAT required kind-of targeted attacks to exploit, but the IP space for v6 is large enough I would expect a dramatic drop in probe traffic. There are 3.4 * 10^38 addresses. It's just too large of a space to casually scan.