Still waiting for AAAA records on news.ycombinator.com. IPv6-only SIP trunking would also be nice, since an IPv4 address is the main cost of hosting a small PBX.
I'm starting to think the RIR's should just start charging increasing YoY maintenance fees on v4 address space for companies that haven't rolled out v6. Those companies, who already have an allocation, are really benefiting from a negative externality. Maybe it's time they start paying for the privilege.
I'd love to just have a firewall between my SIP device and the internet with IPv6 and none of the games routers play these days.
This situation is the result of poor design and roll-out decisions, not the fault of everyone else.
Impossible. You can't communicate between two hosts without both hosts being able to address the other -- and there's no way for an IPv4-only host to pack 128 bits of address into a 32-bit host field.
I think better design could have avoided that issue to begin with by facilitating smooth roll over.
Still, I'd start with translating ipv4 addresses into a reserved range of ipv6 addresses. ...and if ipv4-only clients can't initiate new connections to ipv6 addresses outside that range, OH WELL. (There's probably wiggle room to NAT your way through anyway) More importantly, if there's a default in-built way for ipv6-only machines to initiate connections to ipv4-only machines, and the ipv4 machines can return traffic via some type of NAT, there's a lot more incentive to switch to support ipv6 since more machines would be using it.
That's already a part of IPv6: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
(In fact, when I store IPv4 addresses in memory/files, I just use the IPv6 encoding, which saves having a separate IP version field.)
This is generally referred to as CGN, or Carrier Grade NAT. Article on CGN from 2011, as an example [0].
[0] https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ip...
[0] 10.10.10.10 == ::ffff:0a0a:0a0a
It suffers from a lot of practical problems, which are described at length in RFC 4966. For example, without careful special handling it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets; it breaks IPsec; it can't handle fragmentation; and it suffers from scalability issues.
Well it doesn't break them exactly. An ipv6 capable application would connect to the embedded ipv6 address and not be natted. But it fails to make a legacy application work, so you are no worse off at least.
Many of those can be used even if your own ISP has no support for IPv6 at all. Many of the require manual configuration (as in the case of tunnel brokers) however, which makes it less likely for non-technical users to use them.
But the issue is that some ISPs (and cloud providers) simply don't care or even actively drag their feet (since it may be in their business interest to do so for now).
IPv6 should just have been a superset and 0..1.xxx.yyy.zzz.ttt should have been the legacy IPv4 space. I really don't get the point of all the bizarre block assignments, hexadecimal fetish, and general "why is this seemingly purposefully such a pain in the ass" feeling I get whenever I look at it.