No NAT doesn’t mean no firewall. It just means that you both don’t have to deal with NAT fuckery or the various hacks meant to punch a hole through it.
Behind NAT, hosting multiple instances of some service that uses fixed port numbers requires a load-balancer or proxy that supports virtual hosts. Behind CGNAT, good luck hosting anything.
For “just works” peer to peer services like playing an online co-op game with a friend, users can’t be expected to understand what port forwarding is, let alone how it works. So, we have UPnP for that… except, it doesn’t work behind double NAT, and it’s a gaping security hole because you can expose arbitrary ports of other devices if the router isn’t set up to ignore those requests. Or, if that’s not enough of a bad idea, we have clever abuse of IP packets to trick two routers into thinking they each initiated an outbound connection with the other.
IPv6 has two main types of non-broadcast addresses to think about: link-local (fe80::) and public.
A device can self-assign a link-local address, but it only provides direct access to other devices connected to the same physical network. This would be used for peer discovery, such as asking every device if they are capable of acting as a router.
Once it finds the router, there are two ways it can get an IP address that can reach the wider internet: SLAAC and DHCPv6. SLAAC involves the device picking its own unique address from the block of addresses the router advertises itself as owning, which is likely what you’re concerned about. One option for ensuring a device can’t just pick a different address and pretend to be a new device is by giving it a subset of the router’s full public address space to work with, so no matter what address it picks, it always picks something within a range exclusively assigned to it.
Edit: I butchered the explanation by tying to simplify it. Rewrote it to try again.
In most cases, the router advertises the prefix, and the devices choose their own IPv6. Unless you run DHCPv6 (which really no-one does in reality, I don’t even think android will use it if present).
It doesn’t allow firewall bypass though, as the other commenter noted.
Unless you run DHCPv6 (which really no-one does in reality)
Question for you since I have very little real world IPv6 experience: generally you can provide a lot of useful network information to clients via DHCP, such as the DNS server, autoconfig info for IP phones, etc. how does a network operator ensure that clients get this information if it’s not using DHCPv6?
You can, and there’s a specific flag to set on nd/ra to tell the client to get other information from djcpv6. But so far I’ve not made it work and also, it likely won’t work on android.
Really the way forward is for routers and devices to implement the same options as exist on dhcp. But, time will tell how that gets on.
This is a weakness of ipv6 but it’s really the lack of widespread implementation that’s behind this. If we were all using it, there would be more onus to get this stuff working.
No NAT doesn’t mean no firewall. It just means that you both don’t have to deal with NAT fuckery or the various hacks meant to punch a hole through it.
Behind NAT, hosting multiple instances of some service that uses fixed port numbers requires a load-balancer or proxy that supports virtual hosts. Behind CGNAT, good luck hosting anything.
For “just works” peer to peer services like playing an online co-op game with a friend, users can’t be expected to understand what port forwarding is, let alone how it works. So, we have UPnP for that… except, it doesn’t work behind double NAT, and it’s a gaping security hole because you can expose arbitrary ports of other devices if the router isn’t set up to ignore those requests. Or, if that’s not enough of a bad idea, we have clever abuse of IP packets to trick two routers into thinking they each initiated an outbound connection with the other.
can you tell me if any device in an IPv6 LAN can just assign itself more IP v6 adresses and thereby bypass any fw rule?
IPv6 has two main types of non-broadcast addresses to think about: link-local (fe80::) and public.
A device can self-assign a link-local address, but it only provides direct access to other devices connected to the same physical network. This would be used for peer discovery, such as asking every device if they are capable of acting as a router.
Once it finds the router, there are two ways it can get an IP address that can reach the wider internet: SLAAC and DHCPv6. SLAAC involves the device picking its own unique address from the block of addresses the router advertises itself as owning, which is likely what you’re concerned about. One option for ensuring a device can’t just pick a different address and pretend to be a new device is by giving it a subset of the router’s full public address space to work with, so no matter what address it picks, it always picks something within a range exclusively assigned to it.
Edit: I butchered the explanation by tying to simplify it. Rewrote it to try again.
In most cases, the router advertises the prefix, and the devices choose their own IPv6. Unless you run DHCPv6 (which really no-one does in reality, I don’t even think android will use it if present).
It doesn’t allow firewall bypass though, as the other commenter noted.
Question for you since I have very little real world IPv6 experience: generally you can provide a lot of useful network information to clients via DHCP, such as the DNS server, autoconfig info for IP phones, etc. how does a network operator ensure that clients get this information if it’s not using DHCPv6?
You can include some information in router advertisements, likely there will be rfcs for more. Not sure of the full list of stuff you can advertise.
For sure I’m quite sure I had dns servers configured this way. I’ll check when not on a phone to see what options there are.
If I recall correctly, you can do stateless DHCPv6 to just hand down a DNS server without also managing the devices’ IP addresses.
You can, and there’s a specific flag to set on nd/ra to tell the client to get other information from djcpv6. But so far I’ve not made it work and also, it likely won’t work on android.
Really the way forward is for routers and devices to implement the same options as exist on dhcp. But, time will tell how that gets on.
This is a weakness of ipv6 but it’s really the lack of widespread implementation that’s behind this. If we were all using it, there would be more onus to get this stuff working.
What exactly does Google do for Android, then? Hardcode the IPv6 address of their own DNS service, or fall back to pulling AAAA records over IPv4?