Does anyone know if AWS is going to push the remaining 1% to implement ROA?
Also, it sounds like an unsigned route - which I think most BGP announcements are - is still accepted, right? Any idea when we can start to require routes be signed?
For example, running tests to a signed, unsigned and invalid prefix can provide insight into how other networks are routing to them.
One example is a beacon to probe to determine if a network has enabled origin validation. Failure to connect, or a change in the routing path can provide insight into which networks on the internet have enabled origin validation.
Transitional technologies allow IPv4 holdouts to have "working" Internet despite an increasing proportion of IPv6 nodes, there's some device somewhere which is mapping your connection to some IPv6-only service as an imaginary IPv4 connection. Such things wouldn't scale with 99% of users and usages, but can handle say, five thousand IPv4 users on your ten million customer ISP who mostly visit Facebook and check email.
Eventually the long distance traffic for IPv4 is tiny, because there's a transition device nearer almost all remaining IPv4 users and that's turning their traffic into IPv6 for the long haul anyway.
At that point if you're a backbone provider, IPv4 is a sizeable cost (the routing tables for it are horrendous) for negligible benefit (hardly any of your traffic) and its future only looks more dismal. So you start deprecating this service for your customers, and they don't bother to buy a replacement because they have a transition device to help any residual IPv4 users.
And so one day, without a fanfare, there just isn't really an IPv4 Internet any more, and the RIRs will just deprecate their management of the numbering for that network because it's obsolete.
Ideally this is an obscure nerd event, like a leap second, which your friends at first don't understand, and then when you explain it they realise it's boring and they don't care.
I hope to live to see it.
This is mostly impossible, because an IPv4 packet doesn't have room for an IPv6 destination. The opposite direction (NAT64) is common, but that's for IPv6 clients talking to IPv4 servers.
This doesn't work great, it breaks protocols which assume they're transparent (e.g. some FTP modes), it is slower and clunkier than "just" having IPv4 as we do today, and as I said it isn't viable with huge numbers of users (you run out of address space) but it's good enough that a lot of common application software remains usable this way.
This is about the gentle slope down, so it doesn't need to be perfect or even have the potential to be perfect, it just needs to work well enough to reduce the amount of tech support phone calls.
Think of it like the way pulse dialling was deprecated. Nobody needed to figure out a way to have pulse dialling be as good as tone dialling, let alone a truly out-of-band system (as is used by your mobile phone, and most other modern systems), they just needed to minimise the situation where lots of customers discover that they were using pulse dialling only because now it doesn't work.
Recent developments like DNS over HTTPS make it even less viable.