17) Nobody wants to do work without some actual immediate local reward (in time and space, since IPv6 is surely beneficial from the POV of the world at large), potentially creating N problems.
IPv6 should be studied as an emblematic case of mistake in the approach of the introduction of a new technology.
Yeah I did a bunch of AWS stuff for a new project at the startup I'm at. I tried for five minutes to get ipv6 working across all my VPC stuff. Didn't work. Wouldn't provide immediate benefit. Moved on real quickly.
A sane extension to IPv4 using 64 bit addresses, and not disturbing anything unrelated to address space exhaustion: not replacing ARP with the ICMP-based neighbor bullshit (so that you now need an IP address to get an IP address) and so on.
Even the use of colons in the textual IP address notation is moronic. The colon is already used in a notation for port numbers: 1.2.3.4:567. Under IPv6, you have to use square brackets around the address if it is followed by colon-delimited port number. Ugh!
A 64 bit extension to IP can just use a four-part dotted address, where the parts are 16 bit decimals. Or perhaps an 8 part dotted address. A range of zeros can be two consecutive dots: 10..1 would be 10.0.0.0.0.0.0.1.
People bought several generations of new routers since work on IPv6 began in the early 1990's. If that work had been sanely scoped, we'd all be using IPv6 by now.
People bought new routers, for example, because of faster ethernet and fibre. Faster switching, more ports. Bigger routing tables. At the last hop, also due to Wi-Fi and rounds of newer Wi-Fi.
A smart upgrade to IP could have been hammered out by a team of half a dozen skilled engineers well before Y2K rolled in.
We already have the best upgrade that's actually possible given the design of IPv4 -- the fundamental problem is a combination of the pigeonhole principle (which means there's no way to allow unmodified v4-only hosts to talk to v6 hosts) and the fact that there's nobody in a position to force people to use the necessary modifications.
As a result, we end up with several generations of hardware that support everything necessary but where the people who wrote the config for them are too lazy to actually turn it on.
... and that's how you end up with current situation
Replacing inaddr_t with inaddr6_t is trivial, and does not require any significant effort at all.
Replacing everything else is hard. My house is on IPv4 and will be on IPv4 for foreseeable future, because all of my setup (filtering, metering, monitoring, fixed IP assignment) is completely unusable in the new IPv6 world with privacy extensions where addresses are not only random, but change constantly.
You do know of RFC 7217 address assignment resulting in stable addresses as long as you don't move into another network? It's even the default on some Linux distributions.
If you want predicatable addressing, you can always forego privacy extensions and use EUI64-style interface identifiers.
Yes, I know about RFC 7217. But I also know that default network setup in recent Linuxes, Android and iOS all uses privacy extensions. And even if they can be disabled, I want to keep them -- they are there for a reason, I don't want to give every single internet website a permanent, unique identifier.
This is not an insolvable problem. I can write another daemon to keep the history of IP<->Mac associations, change my accounting scripts to look the matching MAC, change the firewall to filter based on mac address, and so on -- but it is a lot of work, and no benefits.
The NAT is not a problem at my home network, generic openwrt router has enough CPU power for my bandwidth. Direct addressing for each device is useless, as I would still have to list every port and every device I want to expose -- even if NAT goes away, the firewall with default-deny incoming policy stays.
This, IMHO, is the biggest problem with IPv6 adoption. If this was only "recompile the problem and change IP address regex", then we would be done ages ago. Instead, it just got strictly worse for most small network owners.
I quite like the clarity of using link-local addresses within IPv6 addressing, along with scoped multicast. Replacing the functional of ARP from within the protocol (as opposed to ARP itself, which operates as a sibling to IPv4 with its own Ethertype) is quite elegant. DHCPv6 operating without the hack of using destination 255.255.255.255 and source 0.0.0.0 addresses, and thus without requiring special OS level privileges, also feels like a nice simplification.
The strongest rejection of these that I've seen so far is that BT in the UK rolled out IPv6 to all of their residential customers over a year ago now, and have had it in some form for several years.
BT are huge, very slow moving, not very efficient, not considered "cool", not considered to be cutting edge in any way, and most of their residential customers have no idea what IPv6 is. Technically inclined customers who care about this sort of stuff, or early adopters are very unlikely to use BT.
If you're using CGNAT to work around not having an IPv4 address for each user, then rolling out IPv6 reduces load on your CGNAT system to the extent that your users can and do move traffic to IPv6. Many popular sites support it, so there can be a pretty big shift.
Not having to buy IPv4 addresses. CG-NAT infrastructure expenses scale up with customer base. If most of their traffic is end to end IPv6 that's a savings. End point machines like cable modems, TV decoders, VoIP adapters/IP phones, all need their own IP address; service providers with more than 16.7 million managed devices attached need IPv6.
But do the ongoing CGNAT expenses outweigh the potential expenses of transitioning?
I'm with one of, if not the, largest UK ISP and am pretty sure they're not IPv6 ready because their routers have no mention of it (Huawei router firmware updates presumably needed). BT have upgraded the physical infrastructure so I'd expect we'd be there already if there were easy savings.
Lower network traffic (No DHCP and associated overhead), simpler routing (IPv6 is only CIDR). That may not seem like much but that's actually pretty huge to mobile carriers where that can translate into hours of battery life on the device and power costs at the node.
BT aren't really big as a mobile carrier. I think they might offer business services for that, but they are most well known for their residential and business voice and broadband services.
In the 2000s, I was a happy customer of BT Ireland when they provided residential broadband to customers in the South (unfortunately, when Vodafone took over, the quality degraded drastically within weeks). If an Irish ISP provided IPv6 to residents of the Republic, it would be a big incentive for me to switch providers.
I mean, I like how sharing my IPv4 address with neighbors under cgNAT makes e.g. torrent monitoring sites (was on HN some time ago?) mix several people's downloads together into one list lol… but with actual data analysis it shouldn't be hard to separate my activity and the neighbors'
In the end this indeed doesn't really help you much, because the ISP just ends up maintaining a giant database with records of every single connection that they can use to figure out who did what.
The number one excuse in my opinion is: you can't only support IPv6 if you make a service that can interact with anything IPv4, so the real question is not "should I use IPv6 or IPv4?" but rather "Should I use IPv6 and IPv4 or just IPv4?"
Clearly all other things being equal supporting only one stack is easier than two. It's a shame though, at work I've decided to go full IPv6 for one of our software solutions because I'm only talking "to myself" and it's amazing to have so much flexibility in your addressing. Need a unique IP in a distributed system? Just stick your MAC in there and you're good to go. Need a private network prefix that won't clash with anybody, anywhere? Use RFC 4193 and you're good to go.
Not op, but when I went through the exercise, the only difference was that I changed the type of socket I was creating, and I used `getaddrinfo()` to get a list of addresses to bind to vs just binding to a single entity.
There really isn't a whole lot of work that needs to be done to support IPv6 in an application, especially new build.
It was a brand new design so I just used IPv6 from the ground up, there were no adaptation/rewrite involved.
The main cost was the time spent reading the various IPv6 RFCs to make sure I understood the details (it mostly mapped well to my IPv4 knowledge but there are differences). Beyond that it was smooth sailing, although I'm regularly annoyed that common tools are rather clunky when dealing with numerical IPv6 addresses. For instance Firefox requires that I put [] around the IP for it to treat it like an IPv6. SSH on the other hand does not understand the address between brackets. On the other hand SCP does requires the brackets (since it uses a : to delimit the path) which is even more annoying than Firefox because zsh treats [] like a match pattern. It's just small things but it does hurt usability.
Oh and ZeroMQ didn't support IPv6 in their experimental UDP implementation so that was some additional work.
The institutional trading world uses a lot of private network connections, and it would be amazing if the whole industry migrated to IPv6. Then everyone could have a real subnet for each link with genuine globally-unique addresses. It wouldn’t even be a hard migration — vendors force everyone to update their network config on a semi-regular basis anyway.
Honest question, not trying to incite unrest: Why does IPv6 even matter for private networks? My understanding is the main (only?) benefit of IPv6 is the vastly increased address space, are there that many private networks in existence that exhaust all IPv4 private network IP ranges?
While there are 16,777,216 available addresses under 10.0.0.0/8, most organizations will do the reasonable thing of allocating nice regular subnets for each area and use case, so you can easily end up with one org using things like
10.0.0.0/16 for infra
10.8.0.0/16 for allocating end user /24s
10.16.0.0/16 for whatever
and then that org will merge with another who as it turns out did exactly the same thing, and now the internal subnets all overlap. Even though each company may only be using a few thousand addresses, the address space itself overlaps.
Even if you can plan things ahead of time and divided the /8 into 32 /13s or something and give each sub company 500k addresses, you'd still be screwed on a merger.
Even with private networks, having plenty of address bits makes things a lot easier.
My employer's internal network includes hosts with addresses in the 10.0.0.0/8 private address range. So does my home network. I have to be careful when choosing subnets, or else things will break in weird ways when I connect to my work VPN. With IPv6, I don't have to worry about this because every machine can be assumed to have a globally-unique address, even if that address isn't normally exposed to the outside world. And more importantly, it's easy to look at the address prefix and figure out where to route packets.
The right description for most networks in finance isn't really private, but rather semi-public. NYSE's matching engines aren't routable over the public internet, but they'll give access to anybody willing to pay the price. Same goes for any of the hundreds of other exchanges out there. And lots of broker/dealers need to talk to multiple different exchanges, as well as to each other. It would be nice to do all of that communication using one globally unique IP address, rather than with a rats nest of NAT for each gateway.
I’ve seen traceroutes on private network setups that involve a catastrophe of different conflicting uses of 10.whatever addresses. Also, people use NAT on some of these private network for reasons that escape me.
Getting everyone on the same address namespace would be a big simplification.
For institutions on the leading edge, the extra bytes incurred by the IPV6 ethernet frame make it a non starter. 160 bits for IPV4 vs 320bits for IPV6 @ 10GHz is a 16 nanosecond penalty on every message you send.
With those sorts of requirements, it seems like firms would find value in using a different layer-3 protocol (perhaps even custom) to reduce that overhead further.
Yep, the microwave links are often using custom layer 3 tech (1 byte messages!).
Beyond that, you need to vertically integrate a hardware shop and get custom layer 3 hardware, otherwise you're not going to beat off the shelf Arista/Cisco switches doing IPv4 routing.
Also, at the end of the day, you need to be shipping your bytes to an external consumer (e.g. an exchange), so you're probably going to need to have an IPv? layer at some point anyways.
It's crazy the lengths to which trading firms are going to squeeze nanoseconds out of latency. It makes me wonder what value we're getting, from a societal perspective.
I doubt that’s true. HFT is big business but nowhere near that big. Keep in mind that a lot of the big HFT players failed a few years back due to revenues being too small to support the R&D operations. I think that what really made 10G affordable is trickle-down from the SAN world.
You can only forcibly migrate the edge protocol. There will still be competition for small ethernet frames to execute against geo arbitrage opportunities.
What you'll (likely) see is internal networks on V4 and V4->V6 translation switches at the edge so you only pay the 16ns cost on ingress/egress.
Yes, flexibility. You don't need to have 2^24 hosts for a 24-bit address space to start becoming cramped. You have to divide up that space into subnets that roughly match your physical network structure, which depends on accurately anticipating future growth; otherwise you'll have to suffer the pain of renumbering later on.
The real benefit of a /48 or /32 IPv6 subnet isn't that you never run out of individual addresses. It's that you're practically guaranteed never to run out of identifiers at any level of the hierarchy.
I've seen many cases where companies were bought, merged, or linked to other companies and had to put complicated NATs in place to translate org A's 10.* addresses to/from org B's overlapping 10.* addresses.
Then you have the problem of connecting to a VPN for 10.10.0.0/16 from a coffee shop with 10.10.0.1 as its router.
10.* is private. His IPv6-only project was probably using the Internet, so his computing farm at point A could talk with his high performance cluster at point B without a tunnel.
My solution integrates in other networks while having its own private addressing. Think something like a VPN (it's not a VPN but that's a story for an other day). Even if I allocate a random subnet like "10.5.212.0/24" I still take the risk of being unlucky and conflicting with something. On top of that I then only have 256 individual IPs to play with which means that I need to have some kind of dynamic allocation scheme instead of just using the MAC address to have a globally unique ID. This is of course even worse if you want to allocate multiple subnets.
Bingo. It (DSLite) breaks P2P traffic in the sense that there will be less peers available. Which is a big issue for rare material. I also couldn't use 4G to access my network. I kindly asked my ISP (Ziggo NL) to swap back from DSLite to a router with native IPv4. Not in the least because the router was unstable (a known issue with certain consoles even though we didn't use any of these).
Dual stack, OTOH, is no problem but my ISP doesn't provide that (a competitor -XS4ALL- provided it for nearly 20 years now though it was beta for a long time as well and also it has been a tunnel for a few of those years). I feel sorry for our German neighbours with UnityMedia who are stuck with DSLite.
It's not DS-Lite that does that, it's CGNAT. Unfortunately CGNAT on v4 is unavoidable, because there just aren't enough v4 addresses to avoid it, so although it does suck a lot it's hard to blame ISPs for using it. It's just one of the consequences of v4 exhaustion.
DS-Lite makes the situation better by giving you v6, which means you can still do inbound connections. If you just had CGNATed v4 with no v6, then you wouldn't be able to do that at all.
They could inject malicious code or even just ads into those http assets and therefore compromise the https connection.
I also don't necessarily think that we need https for everything, but it's better to err on the safe side and if you're gonna start doing it, then you should do it properly.
My favorite part of this site has got to be the crying double-colon logo!
I do wish IPv6 would come sooner, but it's going to take a real extrinsic reason (e.g. catastrophe) for true mass adoption to happen quickly. Otherwise it's just going to happen slow-as-ever.
Ironically, their excuses make sense in context.
Not all people will find technical superiority as a good argument(Linux vs Windows), as any doubt or excuse will be judged as another benefit of maintaining the status quo.
The cost of switching is a real thing, they don't feel the Ipv4 exhaustion pressure personally and the old thing works.
And there are some unfortunate details in IPv6 deployment decisions that make switching harder or costly enough, just enough to use alternatives fixes(like NAT) or maintain some cludge to route IPv6 without actually supporting it(read https://en.wikipedia.org/wiki/6to4 ).
When it comes to tech migrations I see 3 types of stories.
1. Create "new technology" that is a backward compatible or even drop in replacement for old technologies. Good examples of this is Web technologies, TLS, Linux APIs, bitcoin soft forks etc. This however makes "new technology" vastly more complicated both in concept and in implementation. e.g. writing a conforming web browser from scratch is impossible today.
2. Create "new technologies" that are parallel redesigns and are made "how they should be". The intent is to simplify the technology and fix problems discovered in previous versions. The plan is to run things parallel until people _voluntarily_ switch to "new tech" because it's better. Examples of this is python 2 vs python 3, IPv6, etc.
3. A third approach I guess is making backward compatibility a tool, like it's done with all ANYTHING->ES5 compilers.
(Sidenote: python2to3 tool should have been python3to2 instead)
I’m always in for some laughs, don’t get me wrong. But if there’s something I hate is a list of bad examples (such as “falsehoods programmers think") where there’s no reference to an explanation of why each of those is a bad example.
If you can’t formulate why it‘s a bad example then there’s no way it will be spreaded knowledge.
Mind sharing an example? Not that I don’t believe you, but I’m fully IPV6 on my (admittedly small) home LAN and have IPV6 upstream to my ISP (thank you, Comcast), and everything I need works well. I’d love to know what you had trouble with, simply to verify for myself that I’m not unknowingly broken!
I'm sure it's highly dependent on the equipment. My ISP's router allows you to control the DNS settings for IPv4 but not for IPv6. So I could not reliably re-point the DNS servers. The router also gives the ability add local DNS names for lan addresses and that literally just doesn't work when IPv6 is enabled.
Connecting to a Chromecast from iOS devices was also more hit and miss when IPv6 was enabled. Actually iOS devices seem to have a lot of LAN connectivity issues in general even though they had full access to the Internet. Again, this could be a router issue.
I also have had no issues with a fully dual stack ipv4 and ipv6 network on Comcast. I however do run my own firewall/router, its just a silly openbsd box with some pf firewall rules.
I wouldn't trust any vendor router anyway. Never had issues with ipv6 internally with ios devices either. They're some of the most active ipv6 devices as well with the happy eyeballs or whatever change they seem to prefer ipv6.
I previously didn't have any choice but to use the ISP's router but I recently got fiber and now I'm no longer limited to the router they provide. I might splurge and buy a good one. I used to run my own PC-based router a long time ago but when it became impossible to use with my ISP I dropped it.
Seriously speaking... not a single sysadmin is going to spend time deploying IPv6 for future-proofing while IPv4 is fully maintained and supported.
Best push we can make IPv6 happen is to force all Operating Systems to ditch IPv4 support in favor of IPv6 on their next major version and just play the wait game but nobody is going to do that.
It's slightly curious to see one of these for a (to my best understanding) not particularly politicised as of yet topic, but maybe it is worth reasserting that "I anticipated your argument and put it on a bingo board!" is not a useful or productive counterargument. (cf. Scott Alexander's old post on this tactic in the culture war context: https://web.archive.org/web/20180311015052/https://squid314....)
99 comments
[ 2.8 ms ] story [ 118 ms ] threadIPv6 should be studied as an emblematic case of mistake in the approach of the introduction of a new technology.
https://en.wikipedia.org/wiki/Second-system_effect
Even the use of colons in the textual IP address notation is moronic. The colon is already used in a notation for port numbers: 1.2.3.4:567. Under IPv6, you have to use square brackets around the address if it is followed by colon-delimited port number. Ugh!
A 64 bit extension to IP can just use a four-part dotted address, where the parts are 16 bit decimals. Or perhaps an 8 part dotted address. A range of zeros can be two consecutive dots: 10..1 would be 10.0.0.0.0.0.0.1.
People bought new routers, for example, because of faster ethernet and fibre. Faster switching, more ports. Bigger routing tables. At the last hop, also due to Wi-Fi and rounds of newer Wi-Fi.
A smart upgrade to IP could have been hammered out by a team of half a dozen skilled engineers well before Y2K rolled in.
As a result, we end up with several generations of hardware that support everything necessary but where the people who wrote the config for them are too lazy to actually turn it on.
We might as well take advantage of a compatibility breaking upgrade to fit in all of the other upgrades.
These are the shoals that so many projects have foundered upon.
Replacing inaddr_t with inaddr6_t is trivial, and does not require any significant effort at all.
Replacing everything else is hard. My house is on IPv4 and will be on IPv4 for foreseeable future, because all of my setup (filtering, metering, monitoring, fixed IP assignment) is completely unusable in the new IPv6 world with privacy extensions where addresses are not only random, but change constantly.
If you want predicatable addressing, you can always forego privacy extensions and use EUI64-style interface identifiers.
This is not an insolvable problem. I can write another daemon to keep the history of IP<->Mac associations, change my accounting scripts to look the matching MAC, change the firewall to filter based on mac address, and so on -- but it is a lot of work, and no benefits.
The NAT is not a problem at my home network, generic openwrt router has enough CPU power for my bandwidth. Direct addressing for each device is useless, as I would still have to list every port and every device I want to expose -- even if NAT goes away, the firewall with default-deny incoming policy stays.
This, IMHO, is the biggest problem with IPv6 adoption. If this was only "recompile the problem and change IP address regex", then we would be done ages ago. Instead, it just got strictly worse for most small network owners.
BT are huge, very slow moving, not very efficient, not considered "cool", not considered to be cutting edge in any way, and most of their residential customers have no idea what IPv6 is. Technically inclined customers who care about this sort of stuff, or early adopters are very unlikely to use BT.
If they can do it, anyone can.
I'm with one of, if not the, largest UK ISP and am pretty sure they're not IPv6 ready because their routers have no mention of it (Huawei router firmware updates presumably needed). BT have upgraded the physical infrastructure so I'd expect we'd be there already if there were easy savings.
I mean, I like how sharing my IPv4 address with neighbors under cgNAT makes e.g. torrent monitoring sites (was on HN some time ago?) mix several people's downloads together into one list lol… but with actual data analysis it shouldn't be hard to separate my activity and the neighbors'
And who pays the bill for that? You do.
Clearly all other things being equal supporting only one stack is easier than two. It's a shame though, at work I've decided to go full IPv6 for one of our software solutions because I'm only talking "to myself" and it's amazing to have so much flexibility in your addressing. Need a unique IP in a distributed system? Just stick your MAC in there and you're good to go. Need a private network prefix that won't clash with anybody, anywhere? Use RFC 4193 and you're good to go.
There really isn't a whole lot of work that needs to be done to support IPv6 in an application, especially new build.
The main cost was the time spent reading the various IPv6 RFCs to make sure I understood the details (it mostly mapped well to my IPv4 knowledge but there are differences). Beyond that it was smooth sailing, although I'm regularly annoyed that common tools are rather clunky when dealing with numerical IPv6 addresses. For instance Firefox requires that I put [] around the IP for it to treat it like an IPv6. SSH on the other hand does not understand the address between brackets. On the other hand SCP does requires the brackets (since it uses a : to delimit the path) which is even more annoying than Firefox because zsh treats [] like a match pattern. It's just small things but it does hurt usability.
Oh and ZeroMQ didn't support IPv6 in their experimental UDP implementation so that was some additional work.
No, but there are many private networks in existence that use overlapping subsets of the private network ip ranges.
While there are 16,777,216 available addresses under 10.0.0.0/8, most organizations will do the reasonable thing of allocating nice regular subnets for each area and use case, so you can easily end up with one org using things like
and then that org will merge with another who as it turns out did exactly the same thing, and now the internal subnets all overlap. Even though each company may only be using a few thousand addresses, the address space itself overlaps.Even if you can plan things ahead of time and divided the /8 into 32 /13s or something and give each sub company 500k addresses, you'd still be screwed on a merger.
My employer's internal network includes hosts with addresses in the 10.0.0.0/8 private address range. So does my home network. I have to be careful when choosing subnets, or else things will break in weird ways when I connect to my work VPN. With IPv6, I don't have to worry about this because every machine can be assumed to have a globally-unique address, even if that address isn't normally exposed to the outside world. And more importantly, it's easy to look at the address prefix and figure out where to route packets.
Getting everyone on the same address namespace would be a big simplification.
Beyond that, you need to vertically integrate a hardware shop and get custom layer 3 hardware, otherwise you're not going to beat off the shelf Arista/Cisco switches doing IPv4 routing.
Also, at the end of the day, you need to be shipping your bytes to an external consumer (e.g. an exchange), so you're probably going to need to have an IPv? layer at some point anyways.
What you'll (likely) see is internal networks on V4 and V4->V6 translation switches at the edge so you only pay the 16ns cost on ingress/egress.
More flexibility than having the entire 10.* block to yourself? What are you, Google?
The real benefit of a /48 or /32 IPv6 subnet isn't that you never run out of individual addresses. It's that you're practically guaranteed never to run out of identifiers at any level of the hierarchy.
I've seen many cases where companies were bought, merged, or linked to other companies and had to put complicated NATs in place to translate org A's 10.* addresses to/from org B's overlapping 10.* addresses.
Then you have the problem of connecting to a VPN for 10.10.0.0/16 from a coffee shop with 10.10.0.1 as its router.
IPv6 is much simpler to deal with.
Dual stack, OTOH, is no problem but my ISP doesn't provide that (a competitor -XS4ALL- provided it for nearly 20 years now though it was beta for a long time as well and also it has been a tunnel for a few of those years). I feel sorry for our German neighbours with UnityMedia who are stuck with DSLite.
DS-Lite makes the situation better by giving you v6, which means you can still do inbound connections. If you just had CGNATed v4 with no v6, then you wouldn't be able to do that at all.
This new https craze is like demanding seals of authenticity from posters on lamp posts.
To insert advertisements or "helpful" messages (https://tools.ietf.org/html/rfc6108)
https://tools.ietf.org/html/rfc7258
I also don't necessarily think that we need https for everything, but it's better to err on the safe side and if you're gonna start doing it, then you should do it properly.
I do wish IPv6 would come sooner, but it's going to take a real extrinsic reason (e.g. catastrophe) for true mass adoption to happen quickly. Otherwise it's just going to happen slow-as-ever.
1. Create "new technology" that is a backward compatible or even drop in replacement for old technologies. Good examples of this is Web technologies, TLS, Linux APIs, bitcoin soft forks etc. This however makes "new technology" vastly more complicated both in concept and in implementation. e.g. writing a conforming web browser from scratch is impossible today.
2. Create "new technologies" that are parallel redesigns and are made "how they should be". The intent is to simplify the technology and fix problems discovered in previous versions. The plan is to run things parallel until people _voluntarily_ switch to "new tech" because it's better. Examples of this is python 2 vs python 3, IPv6, etc.
3. A third approach I guess is making backward compatibility a tool, like it's done with all ANYTHING->ES5 compilers.
(Sidenote: python2to3 tool should have been python3to2 instead)
Anyway, our hosting provider wants money to give us a v6 prefix. And that's probably because the RIRs and LIRs also charge a fee.
And I don't understand why wouldn't they allocate prefixes for free to those who already have v4 leases.
Or maybe someone just wants to fleece us.
If you can’t formulate why it‘s a bad example then there’s no way it will be spreaded knowledge.
There's no ROI (return on investment) on deploying IPv6.
Connecting to a Chromecast from iOS devices was also more hit and miss when IPv6 was enabled. Actually iOS devices seem to have a lot of LAN connectivity issues in general even though they had full access to the Internet. Again, this could be a router issue.
I wouldn't trust any vendor router anyway. Never had issues with ipv6 internally with ios devices either. They're some of the most active ipv6 devices as well with the happy eyeballs or whatever change they seem to prefer ipv6.
That's Verizon.
Best push we can make IPv6 happen is to force all Operating Systems to ditch IPv4 support in favor of IPv6 on their next major version and just play the wait game but nobody is going to do that.