There are a lot of shortcomings of IPv6 which prevents it to be widely used (particularly on the consumer network side).
First thing to know is that it shifts responsibilities. The router is not responsible anymore for assigning IPs to the network.
The devices assign their own IP address using SLAAC. You could use DHCPv6, but many devices simply won't support it (windows and android to begin with).
Which brings the following issues:
- No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router. The router will ping both routes, and if the fast one is working, using it as main gateway. When it doesn't answer anymore, the router simply change its route.
Because of NAT, this is transparent to the devices behind its network.
For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix.
The "solution" is to have your own address space, and use BGP to change the routes (which is out of reach for all of private consumers).
- ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN). The problem is that SLAAC only works with /64, below the devices usually won't assign themselves an IP anymore. So you can only have one network, you can't have a Guest network with a different prefix.
- As mentioned by the article, the design is terrible for privacy: SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address.
EDIT: This is wrong. See throw0101a answer below.
- Captive portals: SLAAC does not directly support assigning DNS servers. So most captive portals simply break because the network's firewall blocks DNS requests as long as they don't use the proper DNS server, but the device might simply not even be able to receive it. (SLAAC has an extension where it can tell the device to receive the DNS servers from DHCPv6, but many devices simply ignore it and treat DNS like browsers do with DoH).
EDIT: This is wrong. See throw0101a answer below.
- Security within networks: Because the responsibilities of who assigns IP is shifted to the devices, switches cannot prevent devices to assign themselves IP anymore. So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.
Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT, so some applications took the liberty to assume that their local IP would always be the same visible on the internet. Not sure if that's this particular case for SIP, but it's usually broken with NAT6.
It is far away from transparent. Devices behind the router can't know that a change in Public IP happened and won't reconnect active connections.
One example is Apple's APNS and Android's GCM. In IPv4 multiwan network, after the change they won't receive notifications at all for up to 30 minutes. In IPv6, the router can invalidate the old prefix, and publish a new one immediately.
I think we're talking about a different issue here. MultiWAN does break consumers which do not support reconnecting from a different source IP. But the issue is the same with IPV6, if the prefix changes, the client has to reconnect anyway.
Also, I'm personally not aware of any reliable way of invalidating IPV6 prefixes except waiting for the timeout. (And if it's republishing a RA, devices don't have to listen to it, and the packet might even be lost with an unreliable wifi for example). If I'm wrong here, I'd love to know about it.
See also "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events":
In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit and reliable signaling
of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously employed prefixes), hosts
on the local network may continue using stale prefixes for an
unacceptably long time (on the order of several days), thus resulting
in connectivity problems. This document describes this issue and
discusses operational workarounds that may help to improve network
robustness. Additionally, it highlights areas where further work may
be needed.
> Which means that anybody on the internet gets to know your mac address.
Pretty sure all reasonable devices utilise privacy extensions.
> ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN).
If it's wrong is subjective. If it's not a goal to upsell a business connection there might be technical limitations.
> No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router.
Bit of a niche use-case and still very doable with NAT66.
> Captive portals: SLAAC does not directly support assigning DNS servers.
I haven't seen a captive portal that wasn't able to intercept DNS or that couldn't MITM all connections to display that page. It's a non-issue.
> So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64
IPv4 devices can conduct ARP spoofing, no biggie. If it's "very easy" to do either it's just poor switch software.
A lot of devices (android/windows) simply don't support DHCPv6.
And SLAAC's RA delegates the responsibility of the IP to the device itself, so doing something like DHCP snooping is simply not possible because the RA packet doesn't tell the switch which IP belongs to which device.
SLAAC-snooping protects against ARP poisonning, not against ARP table overflow.
If it doesn't protect against ARP table overflow then that is again a missing feature in that software. Just like it's not IPv4's fault if there are no protections against someone sending a thousand DHCP requests and depleting the pool or filling some tables.
It's not really that there's no support. It's more that the support isn't very good.
In theory, you send router advertisements, with priorities for all your routes, and when a connection drops, you stop sending that route's advertisements or start sending announcements showing that prefix is now didabled. And all the clients would do useful things with it.
But of course, they don't. They'll use an address from Prefix A and send it through router B. Or prefer the first announcement they see rather than the most preferred route. And that's assuming you can convince your CPE to set the preferrences you want.
> For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix.
Is multi-WAN without a static IPv6 assignment common? For home users, generally you get one assignment. If you do need this, then you can use IPv6 ULA internally and NPTv6 for prefix translation. You can still get mostly end-to-end connectivity because the external-internal is stateless. See "IPv6 Multihoming without Network Address Translation:
> SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address.
Except that this hasn't been how its worked on most OSes by default for several years; see "Temporary addresses", "Cryptographically generated addresses", and "Stable privacy addresses":
> So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.
And the same thing can be done with in the IPv4 world by trying to overflow a switch's ARP table. I think switch manufacturers have figured that out.
> Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT
Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless:
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Prefix Translation (NPTv6) function that provides the
address-independence benefit associated with IPv4-to-IPv4 NAT
(NAPT44) and provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end-to-end reachability
at the network layer.
So you can send a message to a packet to a public IP:port combo and it will be mapped to an internal IP:port without much fuss since only the first /64 needs to be re-written. Of course only if your router/firewall is configured to allow new connections, which most consumer CPEs are not by default: they only allow replies to previous outgoing connections.
IMHO, most of the problems you describe haven't been a problem for years.
> Is multi-WAN without a static IPv6 assignment common?
Yes, it’s incredibly common in the small business/retail/food/shop business with fibre primary and cellular backup. These places don’t have the budget for BGP, but can afford an extra €$£20-50/month for a backup cellular circuit. They don’t need static IPs, they just need working outbound internet access. And they want failover to occur within a few seconds, not 30s or 2-3mins.
> And the same thing can be done with in the IPv4 world by trying to overflow a switch's ARP table. I think switch manufacturers have figured that out.
Not really though, because in Ipv4, a DHCP server can be authoritative, and switches can ignore IPs which are not assigned by the DHCP server. That's how it's usually figured out for Ipv4.
> Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless.
Yes, I didn't meant to state anything contrarily to that, but you still break applications which assumes that the local IP is the same than what is visible from a remote server on the internet.
For the captive portals, I stand corrected, and wasn't aware that you can now embed DNS directly in RAs, but stayed with the original implementation which delegates the DNS part to DHCP.
I probably have an outdated understanding of Ipv6, but to be fair it's quite a challenging exactly because of all the amendments that you linked. These are only some of the problems I encountered personally, and as you showed, each individual problem has a different RFC to solve it. You never know how stable they are and if they are properly implemented. And most of the time the safe default is to only work with the initial standard.
Can somebody tell me if I'm wrong on my take but this bug/issue means:
- a github app which had read permission on issues could elevate its permission to write
- a github app which had read permissions to discussions could elevate its permissions to write.
So far if the org/user would have been compromise they would have seen with issues or conversations containing content from the app.
Since these are only examples, I can imagine the case with major impact would be a contents:read elevate to content write. But again with commit signing, this would also be caught by the user.
What did I miss where the impact would have not been visible to the end user/org ?
contents:read to contents:write is a big deal! Just to pick out a random widely used project, nodejs [1] has a number of unsigned commits to the main branch. Their commits could have been tampered with during this timeframe.
I guess I can see it, but branch protection rules and pull requests reviews would also prevent that to happen in my opinion
(also ability to do it with content:write is just speculation from my side, they don't make it clear if it is possible, that would need to be confirmed by github)
I'm not really answering your question here, but sideloading allow alternatives with different goals than google play.
For example F-Droid is actually very big particularly with users trying to get rid of google services on their phones.
But it's a marketplace for opensource apps and services, which most commercial apps are not.
F-Droid architecture is terrible (it could take them weeks to build an app, and since they build all apps updates are severely delayed) and their app is a buggy mess. In other words, F-Droid not being widely used is not an indication of people not wanting to use a third party store per se even if it only carries open source apps.
People want a plug and play solution, not to have to research F-Droid client alternatives and then install third party repos which they don't know if they can trust.
I said if I Google "F-Droid" I should get to a webpage that contains an app that works properly and that comes with good repos preloaded. Similar to how Steam is installed on PCs.
Instead I get a crappy app with very outdated repos. That's not good enough.
After looking at the table, I am ready to swallow my pride. Looks like practical latencies have changed a tiny bit. So me and the person I replied to originally were both wrong
You were wrong about the memory latency¹ increasing, but the memory latency² has increased (substantially) for most systems, while the memory latency³ has indeed decreased. In general, the memory latency¹ has not improved much. Of course, the memory latency⁴ has greatly increased, due to the clock frequency being increased so much to enable the higher bandwidth, while the memory latency¹ stayed mostly the same.
[1] as in: access latency of the DRAM [2] as in: how long does a CPU memory read which is _not_ cached take [3] as in: how long does a CPU memory read on average take [4] as in: CL
No, I was right. Not that it matters, feel free to replace latency with bandwidth. Or replace it with nothing and focus on capacity. It's a blip on my point, which is that the architecture has changed considerably to allow for progress in other areas.
Loot rates are not related to the world seed. The problem here was that he modified loot rate tables.
The world seed only matters for the world generation.
This wouldn't be a silver bullet, many hardware have their own controllers, with their own firmware and their own state that the kernel cannot directly control. And for the same type of hardware some might have a full reset with a power cycle, and other might not.
For some reference you can look at the GPU reset bug for navi 10 and below.
Which brings the following issues:
- No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router. The router will ping both routes, and if the fast one is working, using it as main gateway. When it doesn't answer anymore, the router simply change its route. Because of NAT, this is transparent to the devices behind its network. For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix. The "solution" is to have your own address space, and use BGP to change the routes (which is out of reach for all of private consumers).
- ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN). The problem is that SLAAC only works with /64, below the devices usually won't assign themselves an IP anymore. So you can only have one network, you can't have a Guest network with a different prefix.
- As mentioned by the article, the design is terrible for privacy: SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address. EDIT: This is wrong. See throw0101a answer below.
- Captive portals: SLAAC does not directly support assigning DNS servers. So most captive portals simply break because the network's firewall blocks DNS requests as long as they don't use the proper DNS server, but the device might simply not even be able to receive it. (SLAAC has an extension where it can tell the device to receive the DNS servers from DHCPv6, but many devices simply ignore it and treat DNS like browsers do with DoH). EDIT: This is wrong. See throw0101a answer below.
- Security within networks: Because the responsibilities of who assigns IP is shifted to the devices, switches cannot prevent devices to assign themselves IP anymore. So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.
Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT, so some applications took the liberty to assume that their local IP would always be the same visible on the internet. Not sure if that's this particular case for SIP, but it's usually broken with NAT6.