IPv6 has two main types of addresses: 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, the device can ask it for an IP address. The router may then choose to delegate a block of its own address space to that specific device. Preferably a /64, but it could be as tiny as a /128 (1 address). In any case, the router knows exactly what IP address(es) the device is allowed to use and can choose to block incoming or outgoing packets for all of them (and source addresses outside the allowed range).
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.
Yep, it’s all good. In my opinion, IPv6 routers should just be dropping incoming connections by default. If you want to run services you give your machine a static IPv6 and open ports on that IP/port specifically. It’s actually easier than NAT because you don’t need to translate ports and each IP can use the same ports (multiple web servers on 80/443).
I do agree that the average joe is going to expect NAT level security by default and that would provide that.
From a security perspective, allowing all incoming connections by default is unnecessarily exposing devices to a hostile environment. The average Joe isn’t going to understand the risk unless somebody explained it as “it’s like posting your home address on 4chan and hoping nobody manages to pick your front door lock,” and they’re likely never going to take advantage of the benefits that come from having their device be globally reachable.
Another benefit to not having to deal with NAT is that you can actually host services using the same protocol (e.g. HTTP) on multiple machines without having to resort to alternate port numbers or using a proxy with virtual host support.
DHCPv6 is very much in use with large ISPs. SLAAC only lets you get a single /64 (one network) from the ISP, but if you use DHCPv6, which is also provided ISP side, you can often request a /60 to get you 16 networks to use. Also, DHCPv6 doesn’t base the IPv6 address off the MAC address like SLAAC does, so it is better for device privacy.
Why Android does not support DHCPv6 is beyond me. It’s honestly quite ridiculous as it makes configuring LAN-side DNS and other things a lot easier.
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.
IPv6 has two main types of addresses: 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, the device can ask it for an IP address. The router may then choose to delegate a block of its own address space to that specific device. Preferably a /64, but it could be as tiny as a /128 (1 address). In any case, the router knows exactly what IP address(es) the device is allowed to use and can choose to block incoming or outgoing packets for all of them (and source addresses outside the allowed range).
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.
Yeah, I butchered my answer by trying to simplify the process. I rewrote it in a hopefully more accurate but still simple to understand way.
Yep, it’s all good. In my opinion, IPv6 routers should just be dropping incoming connections by default. If you want to run services you give your machine a static IPv6 and open ports on that IP/port specifically. It’s actually easier than NAT because you don’t need to translate ports and each IP can use the same ports (multiple web servers on 80/443).
I do agree that the average joe is going to expect NAT level security by default and that would provide that.
I absolutely agree with you on all points here.
From a security perspective, allowing all incoming connections by default is unnecessarily exposing devices to a hostile environment. The average Joe isn’t going to understand the risk unless somebody explained it as “it’s like posting your home address on 4chan and hoping nobody manages to pick your front door lock,” and they’re likely never going to take advantage of the benefits that come from having their device be globally reachable.
Another benefit to not having to deal with NAT is that you can actually host services using the same protocol (e.g. HTTP) on multiple machines without having to resort to alternate port numbers or using a proxy with virtual host support.
ok. thank you. stuff like this just made me wonder: https://en.avm.de/service/knowledge-base/dok/FRITZ-Box-7590/573_Configuring-IPv6-in-the-FRITZ-Box/
for linux etc they suggest du enable dhcpv6 and i cant figure out where they adress this in their firewalls. still learning.
Best thing to do to test the firewall is run some kind of server and try to connect to your ipv6 on that port.
Like I’ve said in other posts, routers really should block incoming connections by default. But it’s not always the case that they do.
DHCPv6 is very much in use with large ISPs. SLAAC only lets you get a single /64 (one network) from the ISP, but if you use DHCPv6, which is also provided ISP side, you can often request a /60 to get you 16 networks to use. Also, DHCPv6 doesn’t base the IPv6 address off the MAC address like SLAAC does, so it is better for device privacy.
Why Android does not support DHCPv6 is beyond me. It’s honestly quite ridiculous as it makes configuring LAN-side DNS and other things a lot easier.
Dhcpv6-pd is used by isps for prefix delegation, which most routers support now (not so when my isp first started with it).
But for advertising prefixes on a lan most networks use router adverts.
They’re different use cases though.
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?
Say that you can use prefix delegation. No, really, you can look at the bug report: https://issuetracker.google.com/issues/36949085?pli=1 . It’s absolutely infuriating. Especially when iOS does support it
thanks.