An update on IPv6(potaroo.net)
potaroo.net
An update on IPv6
http://www.potaroo.net/ispcol/2015-06/ipv6.html
13 comments
> I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server.
Quite the calamity if you ask me: Users have to actively ask for the permission to act as a server. And at a significant monetary cost, if I understand the constraints correctly. Sure, right now, nobody has a server at home. But if we did (and this is certainly technically possible), then centralised spying-ridden services such as Gmail, Facebook, and YouTube would be mostly useless. (Assuming peer to peer distribution, you don't need a server farm to scale.)
This would also help with routing by the way, by keeping communications more local.
Quite the calamity if you ask me: Users have to actively ask for the permission to act as a server. And at a significant monetary cost, if I understand the constraints correctly. Sure, right now, nobody has a server at home. But if we did (and this is certainly technically possible), then centralised spying-ridden services such as Gmail, Facebook, and YouTube would be mostly useless. (Assuming peer to peer distribution, you don't need a server farm to scale.)
This would also help with routing by the way, by keeping communications more local.
> right now, nobody has a server at home
I don't think it's that uncommon (and I say that not only because I have one myself). Home routers make it trivial to add one, and NAS boxes are more common than ever. Almost every game and torrent client needs to have ports forwarded (which it a server in the network sense), and UPnP is a "feature" most people have that makes it possible to be unaware of it all.
I don't think it's that uncommon (and I say that not only because I have one myself). Home routers make it trivial to add one, and NAS boxes are more common than ever. Almost every game and torrent client needs to have ports forwarded (which it a server in the network sense), and UPnP is a "feature" most people have that makes it possible to be unaware of it all.
In the US, every ISP contract I've seen says you're not allowed to run a server from your home. And when they structure your connection to have 50mbps down and 0.5mbps up, that's the enforcement.
And that's a pretty unenforceable contract.
A lot of video-games have the host of a match actually work as a server. NAS as servers. In lots of inter-device applications, one of them works as a server. Oh, right, and Xorg.
A lot of video-games have the host of a match actually work as a server. NAS as servers. In lots of inter-device applications, one of them works as a server. Oh, right, and Xorg.
What will happen is that IPv4 addresses won't be free anymore, and you'll have to pay a surcharge. This is already happening with some providers. Also, instead of being given a /29, providers will start handing out /32s. I'm not suggesting this is a good thing, but "calamity" isn't the word that comes to mind.
I'm not sure you comprehend the magnitude of the disaster.
Right now, many people, mostly in countries that are lacking in IPv4 allocation, do not have an internet connection.
An internet connection is a public IP. If you're behind a NAT, or something like it, you don't have a public IP, therefore you are not connnected to the internet. You are connected to a private network, which forwards some of your packets to the open internet. And that server thing. No public IP, no server. Not such a big problem when you control the NAT (assuming it's in your router), and can forward some ports. But if you share the same public IP with 50 other customers, it is theoretically impossible to have more than one HTTP server for those 50 people. The practical limit, of course, is zero.
Right now, many people, mostly in countries that are lacking in IPv4 allocation, do not have an internet connection.
An internet connection is a public IP. If you're behind a NAT, or something like it, you don't have a public IP, therefore you are not connnected to the internet. You are connected to a private network, which forwards some of your packets to the open internet. And that server thing. No public IP, no server. Not such a big problem when you control the NAT (assuming it's in your router), and can forward some ports. But if you share the same public IP with 50 other customers, it is theoretically impossible to have more than one HTTP server for those 50 people. The practical limit, of course, is zero.
"Magnitude of the Disaster" is the type of hyperbole that doesn't bring clarity to the situation.
I've spent the majority of my working life in the last three years happily accessing the internet, internet services, and I've always been behind a PAT device when in a hotel, serviced apartment, etc...
For example, right now, in my Office in Singapore, my IP address is: 192.168.108.34. And I do all my conferences, whiteboarding, VPNs, etc.. from this office.
Now - back to your scenario - You certainly can share a lot of HTTP Servers on a single IP address - a lot of the customers I've worked with do so using PAT, and, you get very used to the port number being part of the HTTP server address:
I.E. http://www.acme.com:3031
In a ultra-low IP address environment, you have teams with not only IPAM (IP address Management tools), but also Port Address Management - they track who has been allocated to which port.
Now - is this the best case scenario? - No, obviously not - it would be awesome to have a Static IP address, and, there are some scenarios in which I have to have a static IP address - in particular getting IPSec VPNs through PAT can be problematic, so if I want to run a VPN concentrator, I start begging and pleading to get a static IP address. But I know this is going to cost me a lot of money. And that's where I started - once we run out of IPv4 addresses, the market will just start bidding the price of them up. Right now, most ISPs in Singapore will give you a static IP address for $120/year. I expect, as they run out of IP addresses, that price will start to increase - and people who might have opted in for one at $120/year, will probably decline at $500/year - returning those IP addresses back into circulation.
At the same time, if someone is sitting on a /20 that they aren't using very using very much (4,000 addresses) - and those IP addresses have $2million/year of value to other people, they will be highly incentivized to capture that value.
With all that said - was it not wonderful to call Layer 42, and, within 30 seconds, be granted 2001:1868:209::/48 off of their /32 ISP range? Yes, it was. I had 65,000 networks I could play with, each of which had effectively infinite address space. Do I look forward to that the day that is universal, in which every ISP user is immediately granted a /64 without asking, and anybody with a home network gets a /56 without paperwork, and a /48 is available with just a quick, inexpensive surcharge? Yes, also looking forward to that.
But - "Disaster" and "Catastrophe" doesn't capture what will happen if IPv4 takes a few extra years to get traction. The market and people's behavior will adjust.
I've spent the majority of my working life in the last three years happily accessing the internet, internet services, and I've always been behind a PAT device when in a hotel, serviced apartment, etc...
For example, right now, in my Office in Singapore, my IP address is: 192.168.108.34. And I do all my conferences, whiteboarding, VPNs, etc.. from this office.
Now - back to your scenario - You certainly can share a lot of HTTP Servers on a single IP address - a lot of the customers I've worked with do so using PAT, and, you get very used to the port number being part of the HTTP server address:
I.E. http://www.acme.com:3031
In a ultra-low IP address environment, you have teams with not only IPAM (IP address Management tools), but also Port Address Management - they track who has been allocated to which port.
Now - is this the best case scenario? - No, obviously not - it would be awesome to have a Static IP address, and, there are some scenarios in which I have to have a static IP address - in particular getting IPSec VPNs through PAT can be problematic, so if I want to run a VPN concentrator, I start begging and pleading to get a static IP address. But I know this is going to cost me a lot of money. And that's where I started - once we run out of IPv4 addresses, the market will just start bidding the price of them up. Right now, most ISPs in Singapore will give you a static IP address for $120/year. I expect, as they run out of IP addresses, that price will start to increase - and people who might have opted in for one at $120/year, will probably decline at $500/year - returning those IP addresses back into circulation.
At the same time, if someone is sitting on a /20 that they aren't using very using very much (4,000 addresses) - and those IP addresses have $2million/year of value to other people, they will be highly incentivized to capture that value.
With all that said - was it not wonderful to call Layer 42, and, within 30 seconds, be granted 2001:1868:209::/48 off of their /32 ISP range? Yes, it was. I had 65,000 networks I could play with, each of which had effectively infinite address space. Do I look forward to that the day that is universal, in which every ISP user is immediately granted a /64 without asking, and anybody with a home network gets a /56 without paperwork, and a /48 is available with just a quick, inexpensive surcharge? Yes, also looking forward to that.
But - "Disaster" and "Catastrophe" doesn't capture what will happen if IPv4 takes a few extra years to get traction. The market and people's behavior will adjust.
The disaster is that app developers can't rely on their users being on the internet in the sense of end-to-end addressability in developing new applications. This has major chilling effects on less centralised types of applications, and tilts the tables toward big content providers and "enterprise" users with "intranets" behind centralized firewalls.
IPv6 deployment is massively late, users have already been conditioned into accepting NAT as internet access, even going so far as NAT boxes being called "routers"- even though NAT flatly contradicts the RFC definition of IP router, which are forbidden from doing port/address NAT along with other arbitrary traffic interference.
IPv6 deployment is massively late, users have already been conditioned into accepting NAT as internet access, even going so far as NAT boxes being called "routers"- even though NAT flatly contradicts the RFC definition of IP router, which are forbidden from doing port/address NAT along with other arbitrary traffic interference.
It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster."
One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance.
Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense.
With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented.
I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.
One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance.
Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense.
With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented.
I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.
> It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster."
My point is, it does. It is not an "end of the wolrd" disaster, but it is an Orwellian one. We're only beginning to realise the insanity behind centralised services such as Gmail. I personally suspected those dangers for a long time, (as did the FSF, the EFF, and many others). Edward Snowden only confirmed some of our worst fears.
That said, the lack of public IP is only half of the catastrophe. The other half is asymmetric bandwidth.
My point is, it does. It is not an "end of the wolrd" disaster, but it is an Orwellian one. We're only beginning to realise the insanity behind centralised services such as Gmail. I personally suspected those dangers for a long time, (as did the FSF, the EFF, and many others). Edward Snowden only confirmed some of our worst fears.
That said, the lack of public IP is only half of the catastrophe. The other half is asymmetric bandwidth.
> lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64
/64 is the smallest network, but there are certainly larger aggregates with smaller prefixes.
/64 is the smallest network, but there are certainly larger aggregates with smaller prefixes.
Yes - you're absolutely right. There are administrative collections of /32s, /48s, /56s - but when it comes time to lighting up a network interface - it's a /64. Even if I only have two devices on a network segment, (two routers that can perform ND with each other), a place that would have used a /30 in the IPv4 space, I'll light up a /64 and burn the other (2^64)-2 addresses. With the possible exception of some security scenarios in which a /127 might be desirable, there is no "address conservation" requirement to use blocks smaller than a /64.
For those IPv4 network engineers who have a decade+ of jugglings /25s, /26s, /27s, /28s and /29s, and trying to preserve IP space (particularly globally routable), this is nice change of affairs.
For those IPv4 network engineers who have a decade+ of jugglings /25s, /26s, /27s, /28s and /29s, and trying to preserve IP space (particularly globally routable), this is nice change of affairs.
Okay, sure, on hosts you're only going to see /64s, but unless I'm seriously misunderstanding something, anyone dealing with route aggregation is going to have to deal with smaller prefixes.
And even just talking about "this is global unicast space", "this is 6to4 space" and "this is link local space" involves small prefixes. So, for example, you still need to do the same mental juggling to know that 2000::/3 is 2000... to 3fff....
And even just talking about "this is global unicast space", "this is 6to4 space" and "this is link local space" involves small prefixes. So, for example, you still need to do the same mental juggling to know that 2000::/3 is 2000... to 3fff....
Agreed. You can't get away from network blocks at the administrative routing level. But, at least life is a bit easier by making more common use of /48s and /32s - I.E. 2001:1868::/32 being 2001:1868:0000:0000::/64 -> 2001:1868:FFFF:FFFF::/64.
Thankfully, the 100x more common task of configuring an interface, will always be a /64.
Thankfully, the 100x more common task of configuring an interface, will always be a /64.
I think he's talking from an end-user point of view.
Even from an end user point of view, the recommendation is to assign a /64 for a single network or a /48 for multiple networks. (Assuming 'end user = homeowner' here.)
And, as it turns out, the original recommendation to go with /48s turned out to be insufficiently flexible, and was overridden with https://tools.ietf.org/html/rfc6177.
In particular, some ISPs will hand out a /56 - allowing the home user 256 /64s. But, once again, these are administrative routing decisions - on the interface, it's always a /64 or (in some rare cases - though I'd love to hear if people still see this in the wild) /127s for router-router connections.
You will never, ever see, for example, a /72 IPv6 network in the wild.
In particular, some ISPs will hand out a /56 - allowing the home user 256 /64s. But, once again, these are administrative routing decisions - on the interface, it's always a /64 or (in some rare cases - though I'd love to hear if people still see this in the wild) /127s for router-router connections.
You will never, ever see, for example, a /72 IPv6 network in the wild.
What I think will really start the network effect is the fact that apple requires APPs for the new iOS to work in a IPv6 only environment. That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6.
So IPv6 only connections will start to become a vialbe end-user product. These will be cheaper than dual-stack installations, so the ISPs will push them.
So IPv6 only connections will start to become a vialbe end-user product. These will be cheaper than dual-stack installations, so the ISPs will push them.
> That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6.
This isn't really necessarily the case. The full details on the requirements for Apple's required "support" for IPv6 are sparse still, but there's no reason that this can't be done with NAT64.
This isn't really necessarily the case. The full details on the requirements for Apple's required "support" for IPv6 are sparse still, but there's no reason that this can't be done with NAT64.
The article briefly touches on this, but I'm mainly interested in IPv6 adoption for the possibilities it opens up in peer-to-peer communications by removing the need for NAT. Imagine the possibilities if WebRTC didn't require the use of STUN/TURN/ICE servers to work properly and browsers could simply talk directly to one another.
I think that is (tin foil hat) perhaps one of the reasons for the hold up. IPv6 makes true p2p possible and will open up a lot of pirating possibilities.
I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits?
You could even have made IPv4 addresses variable length this way, from 32 up to a very large number of bits, and hierarchical. And it's relatively easy to make such a scheme backwards compatible, because you can have (say) a webserver sitting on 1.2.3.4 answering queries for older clients that don't know how to form a 1.2.3.4.5.6 address packet.
You could even have made IPv4 addresses variable length this way, from 32 up to a very large number of bits, and hierarchical. And it's relatively easy to make such a scheme backwards compatible, because you can have (say) a webserver sitting on 1.2.3.4 answering queries for older clients that don't know how to form a 1.2.3.4.5.6 address packet.
[deleted]
Given that you don't want to tie next-generation allocations to existing v4 prefixes, that scheme ends up more complicated than what we got with v6. You would still need a gateway to keep state if you're moving traffic between v4-only endpoints and v6-only, which would end up pretty much like NAT64.
The opportunity to break backwards compatibility in v6 brought many other good things as well: fixed fields that are easier to route, more sane network allocation schemes, router discovery for LANs, and lots of other bits and pieces.
The opportunity to break backwards compatibility in v6 brought many other good things as well: fixed fields that are easier to route, more sane network allocation schemes, router discovery for LANs, and lots of other bits and pieces.
> I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits?
Because that wouldn't be compatible with existing IPv4 deployments and would cause a reliability havoc when a node not configured to deal with it mangled packets transparently somewhere in between your source and destination end-points.
I don't get the resistance against IPv6. It works. It's a fresh take. Yes it requires some new stuff to be deployed and configured here and there, maybe even requires you to learn something new, but if you thought extending IPv4 would have been any other way you are deluding yourself.
If you're going to do a significant change to something as big as the internet (and introducing a new address scheme is that, no matter how you implement it), you might as well step back and think it all through instead of applying yet another hack.
So tell me. Why are you opposed to IPv6? Why do you want to hang on to this old IPv4-thing which is already at the bursting point, at the edge of what it can take?
Because that wouldn't be compatible with existing IPv4 deployments and would cause a reliability havoc when a node not configured to deal with it mangled packets transparently somewhere in between your source and destination end-points.
I don't get the resistance against IPv6. It works. It's a fresh take. Yes it requires some new stuff to be deployed and configured here and there, maybe even requires you to learn something new, but if you thought extending IPv4 would have been any other way you are deluding yourself.
If you're going to do a significant change to something as big as the internet (and introducing a new address scheme is that, no matter how you implement it), you might as well step back and think it all through instead of applying yet another hack.
So tell me. Why are you opposed to IPv6? Why do you want to hang on to this old IPv4-thing which is already at the bursting point, at the edge of what it can take?
I'm not opposed to IPv6. Indeed, I'm one of the few % of people who has a dual-stack home network and ISP. However I don't pretend it was easy to set up - I'm no novice, yet several aspects still confounded me and the large Fedora community that I asked:
http://www.spinics.net/linux/fedora/fedora-users/msg459370.h... (tldr: It's 2015, yet the default firewall in a major Linux distro can't handle IPv6)
http://www.spinics.net/linux/fedora/fedora-users/msg459370.h... (tldr: It's 2015, yet the default firewall in a major Linux distro can't handle IPv6)
> So tell me. Why are you opposed to IPv6?
I'm very concerned about implications for anonymity. If every device has a unique IPv6 address, then just one leak can compromise all other anonymized connections.
I'm very concerned about implications for anonymity. If every device has a unique IPv6 address, then just one leak can compromise all other anonymized connections.
> I'm very concerned about implications for anonymity. If every device has a unique IPv6 address, then just one leak can compromise all other anonymized connections.
IPv4 did not offer any anonymity. The closest you get to that, is an external entity being unable to differentiate the traffic you make vs the one your family makes.
IPv4 did not offer any anonymity. The closest you get to that, is an external entity being unable to differentiate the traffic you make vs the one your family makes.
Check out RFC 4941, "Privacy Extensions". It's probably already implemented on the computer you're using right now.
You can still track the prefix though. In a standard /64 deployment only the suffix will change so there is still some information leaking if you have a static prefix (obviously, as in static IPv4). However, my ISP defaults to dynamic /64 prefix unless you opt in for static prefix. I believe most ISPs should probably do the same.
If you have a dynamic prefix then you can't (easily) run servers; you'd need some sort of dynamic DNS as well. And if you have dynamic DNS and dynamic reverse-resolution…there goes anonymity anyway.
IP isn't anonymous; it wasn't designed to be, and probably (given the problems it's trying to solve) shouldn't be. Anonymity should be an overlay.
IP isn't anonymous; it wasn't designed to be, and probably (given the problems it's trying to solve) shouldn't be. Anonymity should be an overlay.
If you run a server you pretty much need to expose your IP one way or another anyway, even in IPv4. Well, I suppose you can use something like dynamic dns but still...
I totally agree, though, anonymity is not part of IP. I was not implying that, just that there are still ways for home users to somehow shuffle their IPs within the IPv6 framework.
I totally agree, though, anonymity is not part of IP. I was not implying that, just that there are still ways for home users to somehow shuffle their IPs within the IPv6 framework.
If I need to run a server, I anonymously lease hosted VPS or whatever, and SSH via Tor. My concern is keeping my personal Internet connectivity anonymous. I use nested VPN chains, generally using pfSense VMs as VPN clients, and Tor.
I get that the Tor Project is working on IPv6. But I also want IPv6 NAT, in pfSense or whatever. That's to keep my local device IPv6 addresses (hosts and VMs) private, even from Tor entry guards. I guess that it's time to learn how to ensure that.
I get that the Tor Project is working on IPv6. But I also want IPv6 NAT, in pfSense or whatever. That's to keep my local device IPv6 addresses (hosts and VMs) private, even from Tor entry guards. I guess that it's time to learn how to ensure that.
No version of IP provides anonymity reliably. If you want anonymity, use something designed for that purpose, like Tor, use it from a coffee shop, and pay cash.
Various forms of this were actually considered. They all share the characteristic that you discover old v4-only devices late rather than early. You can run a mostly-v6 network and have no way to search for the remaining v4-only devices (or programs). That problem was held to be too much of an "ouch".
> you discover old v4-only devices late rather than early
Could you explain what this means?
Could you explain what this means?
Suppose you have a network with a hundred devices and an addressing scheme that allows 256. You add an extension such that you can use 65536 addresses, and add another 150 devices. Now you have six addresses left under the old scheme (and lots under the new).
But do you have a way to discover whether any of the first hundred devices break soon? Or even the 150 new devices? You could add a device on a new-only address before you run completely out of the old-compatible addresses, but that won't test completely. There might still be devices that will connect, but log the connections improperly, or have a buffer overrun and crash randomly, or, or, or. There might be software on a device that supports only old addresses, even though the device itself supports the extension scheme.
If the network is a big one, where different parties own and operate the devices, then you may well be completely unable to test whether the extension scheme is universally supported. Before the day when you run completely out of unextended addresses, that is.
Contrast this with a dualstack approach, where you can make a list at any time: THESE devices are on v4 only and will be a problem when v4 runs out, THOSE OTHERS are on v4+v6.
But do you have a way to discover whether any of the first hundred devices break soon? Or even the 150 new devices? You could add a device on a new-only address before you run completely out of the old-compatible addresses, but that won't test completely. There might still be devices that will connect, but log the connections improperly, or have a buffer overrun and crash randomly, or, or, or. There might be software on a device that supports only old addresses, even though the device itself supports the extension scheme.
If the network is a big one, where different parties own and operate the devices, then you may well be completely unable to test whether the extension scheme is universally supported. Before the day when you run completely out of unextended addresses, that is.
Contrast this with a dualstack approach, where you can make a list at any time: THESE devices are on v4 only and will be a problem when v4 runs out, THOSE OTHERS are on v4+v6.
I am overcome by a desire to mention an anecdote... about the financial-services company with three old servers that didn't support the new buzzword, but there was some magic compatibility and everything seemed to work. Until there was a lawsuit, a subpoena and it turned out that data sent among the three old servers used some legacy protocol without mandatory logging as demanded by law.
IP options were not an option, unfortunately.
One of the many studies: http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24...
One of the many studies: http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24...
That study is about using options on the network today, not really about creating a standard for the options that would handle the address space issue with the knowledge that support would roll out over time.
Any solution will involve some changes to network infrastructure.
If they had simply added some bytes to the address and not tried to tackle every other perceived wrong with IPv4, we wouldn't be talking about this exact same problem 17 years after IPv6 was introduced.
Any solution will involve some changes to network infrastructure.
If they had simply added some bytes to the address and not tried to tackle every other perceived wrong with IPv4, we wouldn't be talking about this exact same problem 17 years after IPv6 was introduced.
What I don't understand is what is the cost to an ISP of switching. Whether it is network devices or users devices, unless they are more than 10yo, I would expect them to be all IPv6 compatible. So yes it will involve some reconfiguration, training engineers and support, but it looks like a relatively small investment to me. The switch to optic fibre is a way bigger investment.
Financial cost, even in training, isn't high. It's mostly two things - Inertia, and ROI. All of the network engineers know IPv4 ins and out really, really well, and have a mindset of not messing with stuff that's working. And ROI - what financial incentives does an ISP have to switch to IPv6, either in increased revenue or reduced costs?
There's also considerable cost in being an early bird. You get to find all the chinks in the protocol, all the bodgy firmware issues... all for no substantial change to the income stream.
The cost (in addition to those that other replies have pointed out) is also one of support. While a <10yr old device may support IPv6, it is often that they don't always perform exactly as designed. IPv4 & IPv6 co-existence is a little bit of a crapshoot at the device level.
This translates into super-large ramifications, especially for companies like Comcast--I can only imagine that they don't want to add yet another possible moving part, especially when there's almost zero benefit to the average customer.
This translates into super-large ramifications, especially for companies like Comcast--I can only imagine that they don't want to add yet another possible moving part, especially when there's almost zero benefit to the average customer.
That's a very reasonable position, especially with Comcast. Comcast has, in fact, led the IPv6 charge in terms of sizable US ISPs. The flip side of that coin is they have the money to invest in the engineering costs. I assume they did some analysis, computed the cost of NAT vs. IPv6, knowing full-well they'd have to do IPv6 sometime, and plowed ahead.
It's the smaller ISPs that are just used to fixing stuff "when its broken" that are really in trouble.
It's the smaller ISPs that are just used to fixing stuff "when its broken" that are really in trouble.
The cost and inertia is certainly very understandable, and it's nice to see Comcast being somewhat proactive here when compared with the rest.
What does surprise me though is that IPv6 hasn't seen steady uptake when new companies set up new infrastructure from scratch or existing companies upgrade their kit. I would have thought that using IPv6 exclusively internally with DNS64/NAT64 to bridge the external IPv4 internet would offer some advantages.
What does surprise me though is that IPv6 hasn't seen steady uptake when new companies set up new infrastructure from scratch or existing companies upgrade their kit. I would have thought that using IPv6 exclusively internally with DNS64/NAT64 to bridge the external IPv4 internet would offer some advantages.
It's not just a matter of implementing "enable_ipv6 = yes" on a cisco router.
Here's an enterprise perspective:
It's IP address management. it's massive reconfiguration of every node and network endpoint. It's auditing and completely redeploying security measures that are network based. It's training every IT employee on network basics from the ground up.
It's millions upon millions of dollars in man-hours and infrastructure and tooling for something that might have marginal benefit on an internal network. I agree the new world will be better with larger subnets and many of the features of IPv6, but it's more complex.
Fiber-optic and hardware level upgrades touch a lot fewer devices, and are transparent to users and applications.
Here's an enterprise perspective:
It's IP address management. it's massive reconfiguration of every node and network endpoint. It's auditing and completely redeploying security measures that are network based. It's training every IT employee on network basics from the ground up.
It's millions upon millions of dollars in man-hours and infrastructure and tooling for something that might have marginal benefit on an internal network. I agree the new world will be better with larger subnets and many of the features of IPv6, but it's more complex.
Fiber-optic and hardware level upgrades touch a lot fewer devices, and are transparent to users and applications.
>What I don't understand is what is the cost to an ISP of switching
From what I've heard from cable companies is Cisco. They've had many issues with Cisco interop IPv6 on HCF networks.
From what I've heard from cable companies is Cisco. They've had many issues with Cisco interop IPv6 on HCF networks.
Most ISPs have boxes that sit in racks many kilometers from the closest employee and Simply Have To Work. Of course they are conservative about configuration changes.
training and reconfiguration - and more pointedly B/OSS changes - are generally more expensive (opex) than upgrading equipment (capex)
I personally believe the biggest driver for IPv6 adoption will be Apple requiring support in iOS apps. Right now, IPv4 space is still comparatively "cheap"
I personally believe the biggest driver for IPv6 adoption will be Apple requiring support in iOS apps. Right now, IPv4 space is still comparatively "cheap"
IPv4+NAT still works well, because the internet is more and more centralized. Sadly.
No, NAT doesn't work well at all. Everybody that says this isn't taking into account the massive amount of software that wasn't even started in the first place because it wouldn't work behind a NAT.
In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection.
One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority.
[1] https://www.fourmilab.ch/documents/digital-imprimatur/
In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection.
One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority.
[1] https://www.fourmilab.ch/documents/digital-imprimatur/
>In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection.
IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't allow inbound connections, so there will still be the need for some kind of way to allow the client to tell the router to forward traffic on a specific port (likely https://en.wikipedia.org/wiki/Port_Control_Protocol).
Which is exactly the same as we get these days with NAP-PMP or UPnP.
Maybe once listening on all local interfaces will not listen on temporary addresses, we can move to a one-address-per-service model at which point it becomes more feasible to forego the central firewall dropping all incoming connections as port-scanning the machine you just got a connection from will involve scanning 65536 * 2^64 ports
As it stands now, I'm not willing to expose all open ports of my internal machines over IPv6. Instead I still have specific port opening rules on my central firewall.
While I have no issue exposing, say, Skype on some port, I certainly don't want to expose, say, my local NTP port of my Mac, or, worse some local port mapper needed for NFS mounts.
Yes. I could use a local firewall, but these by default only allow a per-application setup. "Do you want to allow NTP to be reachable?" - To my local network? Yeah. Maybe. To the internet? Hell no.
Current simple built-in firewalls don't allow this kind of answer - at least on the mac.
IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't allow inbound connections, so there will still be the need for some kind of way to allow the client to tell the router to forward traffic on a specific port (likely https://en.wikipedia.org/wiki/Port_Control_Protocol).
Which is exactly the same as we get these days with NAP-PMP or UPnP.
Maybe once listening on all local interfaces will not listen on temporary addresses, we can move to a one-address-per-service model at which point it becomes more feasible to forego the central firewall dropping all incoming connections as port-scanning the machine you just got a connection from will involve scanning 65536 * 2^64 ports
As it stands now, I'm not willing to expose all open ports of my internal machines over IPv6. Instead I still have specific port opening rules on my central firewall.
While I have no issue exposing, say, Skype on some port, I certainly don't want to expose, say, my local NTP port of my Mac, or, worse some local port mapper needed for NFS mounts.
Yes. I could use a local firewall, but these by default only allow a per-application setup. "Do you want to allow NTP to be reachable?" - To my local network? Yeah. Maybe. To the internet? Hell no.
Current simple built-in firewalls don't allow this kind of answer - at least on the mac.
I never claimed anything about IPv6, though it would fix most of the NAT problem. Most of what you're talking about is based on how the current NAT infrastructure works... which was sort of my point: NAT badly limits the scope of how we think about software, because so many designs rely on being being able to even name hosts uniquely. Designing software for the NAT "party-line" suddenly requires inventing things like remapping ports to make anything work.
A particularly bad misconception that ubiquitous NAT has encouraged is the conflating of the address-translation step (NAT) with the firewall, when the two concepts are not related at all. You can run either independently of the other[1].
All that is needed for a home router is a simple firewall, and a way to open holes in the router's firewall from the internal hosts. The fact that this software isn't already available on most OS/home-routers is simple lack of demand... and the fact that it would be totally useless for current NATed home networks. You don't need all of UPNP or NAT-PMP; there are no ports that need to be mapped. The difficulty in introducing something to allow certain types of packets through a firewall is trivial compared to the complexity of working around NAT.
Concerns about port scanning and "expose all open ports" are just nonsense, and has nothing to do with NAT. This all-or-nothing approach you seem to be assuming misses the entire point of having an external firewall (such as on an home router). You get to pick which packets you let through.
[1] This is why NAT doesn't provide security on it's own. Static NAT, for example, is just substituting the address; all packets to the public address are forwarded to the translated address.
A particularly bad misconception that ubiquitous NAT has encouraged is the conflating of the address-translation step (NAT) with the firewall, when the two concepts are not related at all. You can run either independently of the other[1].
All that is needed for a home router is a simple firewall, and a way to open holes in the router's firewall from the internal hosts. The fact that this software isn't already available on most OS/home-routers is simple lack of demand... and the fact that it would be totally useless for current NATed home networks. You don't need all of UPNP or NAT-PMP; there are no ports that need to be mapped. The difficulty in introducing something to allow certain types of packets through a firewall is trivial compared to the complexity of working around NAT.
Concerns about port scanning and "expose all open ports" are just nonsense, and has nothing to do with NAT. This all-or-nothing approach you seem to be assuming misses the entire point of having an external firewall (such as on an home router). You get to pick which packets you let through.
[1] This is why NAT doesn't provide security on it's own. Static NAT, for example, is just substituting the address; all packets to the public address are forwarded to the translated address.
Sure but think about carrier nat. IPv6 can also always guarantee that the external port is also always going to be free.
> In fact, I would suggest that NAT is responsible for a lot of that centralization,
They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
> In fact, I would suggest that NAT is responsible for a lot of that centralization (...)
Wasn't that exactly GP's point?
Wasn't that exactly GP's point?
If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly also going to end up as no more than that because IPv6 does not necessarily require people to support more than that?
If so, then that could mean that packet sizes are going to be constant over the next 20 years, all the while that protocols and pipes get many times faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes (relative to faster and faster networks) are going to mean tremendous packet switching overhead (routing, encryption) especially in protocols such as QUIC which try to align encryption with packets.
Sort of like a plane having to stop at every red light in a traffic grid designed for cars.
If so, then that could mean that packet sizes are going to be constant over the next 20 years, all the while that protocols and pipes get many times faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes (relative to faster and faster networks) are going to mean tremendous packet switching overhead (routing, encryption) especially in protocols such as QUIC which try to align encryption with packets.
Sort of like a plane having to stop at every red light in a traffic grid designed for cars.
https://tools.ietf.org/html/rfc1981 : path MTU discovery SHOULD be implemented in IPv6.
Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).
You have to realize that RFCs are not a cudgel to bludgeon people into acting how you would like them to, that never ever works out in reality (at one point IPSEC was a mandatory MUST for ipv6 deployments) because people are free to just ignore them if it makes their life too difficult, and trust me they can and will, no matter what any standard says.
RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored.
Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it.
Rough consensus and running code.
RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored.
Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it.
Rough consensus and running code.
I doubt that "how things actually work on the internet" is "generally" reflected by RFCs. The history of the internet is people trying to work around and fix RFCs actually ("at least with the popular ones"). If you're going to say "SHOULD" you may as well leave it out because people won't follow it.
You are still taking a way too strongly legalistic view of things, standards are not laws (usually). Its not a "everybody conforms to the spec 100% or its worthless" situation in the vast majority of cases.
SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
Frankly, the original concern is that fixed packet sizes relative to increasing capabilities are not a good idea for future hardware and software performance (think silly window syndrome or allocating a million 1-byte buffers). It's a technical problem that needs a technical solution (preferably through clearer language describing the issue or else we need to rethink things). I guess most people are simply not writing protocols that will be influenced by these decisions, so they fail to see the impact.
Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.
Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.
the implied goal of changing a SHOULD to a MUST is to force people to comply, im simply trying to communicate that its really not that simple.
Are they really going to increase in speed? With 10GBit ethernet, we are getting close to the speed at which you transfer data in and out of RAM. I am sure we would like to have faster networks but will we be able to use faster networks (I mean for the end user)?
> close to the speed at which you transfer data in and out of RAM
On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits
On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits
I am looking forward to the day when global IPv4 gets turned off.
They should do it on a World IPv6 Day, how about 6/6/16?
They should do it on a World IPv6 Day, how about 6/6/16?
Might take a bit longer.
Looking at http://www.google.com/intl/en/ipv6/statistics.html it's doubling every year. So it's going to take another four to reach everywhere.
Maybe 6/6/2020 :-)
(And there are plenty of IPv4-only devices out there, like printers, Consoles, etc. So I suspect another five years after that before there's so little left that the address space starts clearing up again.)
Looking at http://www.google.com/intl/en/ipv6/statistics.html it's doubling every year. So it's going to take another four to reach everywhere.
Maybe 6/6/2020 :-)
(And there are plenty of IPv4-only devices out there, like printers, Consoles, etc. So I suspect another five years after that before there's so little left that the address space starts clearing up again.)
This are the video/slides of the talk that Geoff Huston (author of the post) gave at the last RIPE70:
https://ripe70.ripe.net/archives/video/118/
Very interesting point of view imho ("bring IPv6 to the rich first, the others will follow").
Very interesting point of view imho ("bring IPv6 to the rich first, the others will follow").
Wall of text.
I still don't know how to use IPV6. Maybe it is just too complicated and they should come up with something simpler?
I still don't know how to use IPV6. Maybe it is just too complicated and they should come up with something simpler?
IPv6 is not complicated.
128 bits of address space. Everyone gets a /64's (128-64=>64 bits of address space). Larger entities get /48's (128-48=>80 bits of address space). So everyone (you, your device, your network) has plenty of addresses to spare.
Addresses are written in hex, in the form 0011:2233:4455:6677:8899:aabb:ccdd:eeff (that's 8 groups of 16 bits -> 128 bits). If there are zeroes in an address on, you can omit them (ie. 1122:3344:5566:0000:0000:0000:0000:1234 => 1122:3344:5566::1234).
Some protocols (ARP, kinda DHCP, ICMP) are merged into a single procotol called NDP (neighbor discovery protocol).
When you're a home user, your router/gateway/CPE would get a /64 from your ISP, for example 2001:1234:4567:89ab::0/64. to use for your local devices. For example, in your LAN, your router would probably be 2001:1234:4567:89ab::1, while your devices would probably be addressed between 2001:1234:4567:89ab::2 and 2001:1234:4567:89ab:ffff:ffff:ffff:ffff.
If your router is not using DHCPv6, but instead only NDP, it would simply respond with a “we're using 2001:1234:4567:89ab::0/64 here, I'm your gateway” to every device coming into the LAN, and the device would choose an address based on it's NIC MAC and some other facts. If your router would be using DHCPv6, the exchange would be just like in ordinary DHCP (dhcp request -> dhcp reply with IPv6 address to use).
There is some extra (standarized) link-local magic with IPv6 - if you seen an fe80::0/16 address on your link, then it means that there was no IPv6 router/DHCP server on there and the devices in the LAN are establishing connection independently - but of course, without any access to the rest of the IPv6 Internet. This is also done via NDP, IIRC.
And that's basically it. No NAT. The devices in your LAN are directly routable to devices in your friend's LAN, or to Facebook's server
128 bits of address space. Everyone gets a /64's (128-64=>64 bits of address space). Larger entities get /48's (128-48=>80 bits of address space). So everyone (you, your device, your network) has plenty of addresses to spare.
Addresses are written in hex, in the form 0011:2233:4455:6677:8899:aabb:ccdd:eeff (that's 8 groups of 16 bits -> 128 bits). If there are zeroes in an address on, you can omit them (ie. 1122:3344:5566:0000:0000:0000:0000:1234 => 1122:3344:5566::1234).
Some protocols (ARP, kinda DHCP, ICMP) are merged into a single procotol called NDP (neighbor discovery protocol).
When you're a home user, your router/gateway/CPE would get a /64 from your ISP, for example 2001:1234:4567:89ab::0/64. to use for your local devices. For example, in your LAN, your router would probably be 2001:1234:4567:89ab::1, while your devices would probably be addressed between 2001:1234:4567:89ab::2 and 2001:1234:4567:89ab:ffff:ffff:ffff:ffff.
If your router is not using DHCPv6, but instead only NDP, it would simply respond with a “we're using 2001:1234:4567:89ab::0/64 here, I'm your gateway” to every device coming into the LAN, and the device would choose an address based on it's NIC MAC and some other facts. If your router would be using DHCPv6, the exchange would be just like in ordinary DHCP (dhcp request -> dhcp reply with IPv6 address to use).
There is some extra (standarized) link-local magic with IPv6 - if you seen an fe80::0/16 address on your link, then it means that there was no IPv6 router/DHCP server on there and the devices in the LAN are establishing connection independently - but of course, without any access to the rest of the IPv6 Internet. This is also done via NDP, IIRC.
And that's basically it. No NAT. The devices in your LAN are directly routable to devices in your friend's LAN, or to Facebook's server
Stupid question time.
Is there anything in all this that can make my machine behind the router get the same address all the time? Do I manually assign it locally as with IPv4 and hope no one else in the building assigns the same IP?
Is there anything to assign IP-to-Hostname at least on the local (behind the gateway) level. Or is this handled via some other service I need to run (maybe some server that runs dns and allows machines to push their desired hostname to it).
Is there anything in all this that can make my machine behind the router get the same address all the time? Do I manually assign it locally as with IPv4 and hope no one else in the building assigns the same IP?
Is there anything to assign IP-to-Hostname at least on the local (behind the gateway) level. Or is this handled via some other service I need to run (maybe some server that runs dns and allows machines to push their desired hostname to it).
It's done automatically by your router and your OS. By default you won't need to do anything--you plug it in and it just works.
On the machine I'm writing this reply on, when I boot it up (with either FreeBSD, Linux or Windows) it gets a router advertisement from the router (which is routing both IPv4 and IPv6). It gets a standard NATed DHCP lease for IPv4. For IPv6, it combines the /64 network prefix assigned by my ISP with the NIC MAC address to compute a unique (and stable) address.
There are of course alternatives. I can assign it statically, I can use privacy extensions to periodically change the address (seems to be the default on Windows for me) or I can use DHCPv6 to use DHCP-allocated addresses (my router doesn't support this though I have done it in the past with BIND).
On the machine I'm writing this reply on, when I boot it up (with either FreeBSD, Linux or Windows) it gets a router advertisement from the router (which is routing both IPv4 and IPv6). It gets a standard NATed DHCP lease for IPv4. For IPv6, it combines the /64 network prefix assigned by my ISP with the NIC MAC address to compute a unique (and stable) address.
There are of course alternatives. I can assign it statically, I can use privacy extensions to periodically change the address (seems to be the default on Windows for me) or I can use DHCPv6 to use DHCP-allocated addresses (my router doesn't support this though I have done it in the past with BIND).
There are multiple ways of assigning ipv6 addresses. The original way would actually give it the same address every time (48 of the lower 64 bits was based off of the MAC address and the remaining 16 bits were fixed). This has some privacy implications though (You now can be uniquely identified by the bottom 64-bits even when you change networks), so there are other ways of doing it, including a version of DHCP for ipv6.
you'd handle that in the same way you'd handle it in IPv4: either a static assignment & a tracking process to avoid collisions, or static assignments in DHCP. DHCP6 does exist, and static assignments within a DHCP scope is a very common feature.
one caveat: DHCP6 is younger than IPv6, so not all router firmwares will have gotten around to implementing it yet.
one caveat: DHCP6 is younger than IPv6, so not all router firmwares will have gotten around to implementing it yet.
OK, but how do I turn it on? Why is it not turned on everywhere yet? How do I turn it on on my router, and how do I turn it on on my server? Can I just write "useipv6=true" in some config file and I am good?
Do I want to turn it on - do I get some benefit, or would I just do it for the greater good? I've heard it's actually better for the spying agencies?
Do I want to turn it on - do I get some benefit, or would I just do it for the greater good? I've heard it's actually better for the spying agencies?
OS-wise it's probably already turned on. If you take your Mac OSX or Linux PC into an IPv6 network, it will just work. There are however few such networks, because ISPs don't really givae a fuck (also they need to change their configurarion/equipment/CPEs).
Some of the nicer profits of IPv6 for hacker is that you can host servers at home, and expose them to friends/clients.
As for "spying", yes someone (a website you connect to) can figure out whether it's you or your roommate who are connecting. But they can figure that out by browser headers, anyway. This is also partially mitigated by RFC4941.
Some of the nicer profits of IPv6 for hacker is that you can host servers at home, and expose them to friends/clients.
As for "spying", yes someone (a website you connect to) can figure out whether it's you or your roommate who are connecting. But they can figure that out by browser headers, anyway. This is also partially mitigated by RFC4941.
When you mentioned servers, you reminded me of something neglected from your initial writeup that's a bit important to understand: for many years, people have ran with NAT as a de-facto firewall for incoming connections to their devices. With IPv6, since the hosts are now on a routable public network, they need to have proper firewalling enabled. (It's as simple as accept related/established, deny invalid, accept icmp.)
Yes, of course.
2002 explanation by Dan Bernstein of why IPv6 will never happen.
http://cr.yp.to/djbdns/ipv6mess.html
Daniel is a smart guy, but this particular post doesn't really come off as being super coherent... I don't know if it's because of how far IPv6 has come and things are competly different now, making his concerns solved problems, or if he just didn't really grasp everything about IPv6 then (the examples of IPv6 addresses look nothing like actual addresses, and he seems to not have heard of dual stack...). I'd guess it's a bit of both.
DJB was not arguing that IPv6 would never happen. He was arguing that there are some significant barriers that need to be overcome before meaningful adoption will occur.
I'd argue that many, if not all of the issues with v6 back in 2002 have been resolved, and that v6 adoption is accelerating, both on eyeball networks as well as on public-facing internet services.
I'd argue that many, if not all of the issues with v6 back in 2002 have been resolved, and that v6 adoption is accelerating, both on eyeball networks as well as on public-facing internet services.
Figures 3, 4, 5, and 6 are all showing the thumbnail for Figure 6.
Have to say I'm fairly unimpressed by how bad the UK looks in these rankings. The government ought to be incentivising take-up if they don't want the country to be a technology backwater.
I work in a lot of regions in the world, (Mexico, UAE), where they've been used to the reality that they won't be assigned any IPv4 addresses. I'm talking about large $Billion+ organizations that made it abundantly clear to me, that the applications we were deploying ($100million plus network deployments) - would have to operate with PAT, or we would not be able to deploy them.
And so we worked around the requirements that we deploy everything on PAT, and our network deployments (sometimes with thousands of IPV4 network elements) would have to operate purely within RFC1918 address space.
Speaking as someone who has worked on million+ IPv6 node deployments, (So I clearly don't have a bias against IPv6) I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server. Everyone else will be fine. (Have been fine for years in places where public IPv4 addresses ceased to be available).
The reality is that this lack of pressure to transfer to IPv6 means that we're going to see an extended period of time in which we migrate. It will happen eventually (IPv6 has a lot of awesome features, particularly around self-addressing, and lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64) - but it's going to be a lot longer than most IPv6 advocates would prefer.