A brief history of IPv4 address space exhaustion(blogs.igalia.com)
blogs.igalia.com
A brief history of IPv4 address space exhaustion
https://blogs.igalia.com/dpino/2017/05/25/ipv4-exhaustion/
88 comments
I don't think that perception is accurate. Google's IPv6 tracker shows continual progress: https://www.google.com/intl/en/ipv6/statistics.html (with the expected bumps around weekends and holidays)
It's not a fast process, but I don't see any evidence it is stalled.
It's not a fast process, but I don't see any evidence it is stalled.
I don't think it really matters what percent of clients are IPv6-capable. Nobody is incentivized to actually deploy servers to IPv6 while there exist zero IPv6-only clients.
> Nobody is incentivized to actually deploy servers to IPv6 while there exist zero IPv6-only clients.
Facebook is a counterexample.
> Over the past few years, Facebook has been transitioning its data center infrastructure from IPv4 to IPv6. We began by dual-stacking our internal network — adding IPv6 to all IPv4 infrastructure — and decided that all new data center clusters would be brought online as IPv6-only. We then worked on moving all applications and services running in our data centers to use and support IPv6. Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only. We anticipate moving our entire fleet to IPv6 and retiring the remaining IPv4 clusters over the next few years.
https://code.facebook.com/posts/635645183305089/legacy-suppo...
Facebook is a counterexample.
> Over the past few years, Facebook has been transitioning its data center infrastructure from IPv4 to IPv6. We began by dual-stacking our internal network — adding IPv6 to all IPv4 infrastructure — and decided that all new data center clusters would be brought online as IPv6-only. We then worked on moving all applications and services running in our data centers to use and support IPv6. Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only. We anticipate moving our entire fleet to IPv6 and retiring the remaining IPv4 clusters over the next few years.
https://code.facebook.com/posts/635645183305089/legacy-suppo...
They might have actually done it, but my point is that the incentives for companies to do so generally aren't there. And as long as there exist some large sites that believe the costs to adopting IPv6 exceed the benefits, ISPs will continue to give IPv4 addresses to their clients.
My phone's IP is in the private 10 range. A request to Facebook must go through the provider's expensive NAT router.
If they assigned my phone an IPV6 address in addition, that traffic could go directly to Facebook through cheaper switches, which is faster for me, and cheaper for them.
If they assigned my phone an IPV6 address in addition, that traffic could go directly to Facebook through cheaper switches, which is faster for me, and cheaper for them.
The main benefit of IPv6 is that it allows all endpoints to have a real IPv6 address, including the ones that don't have a real IPv4 address.
It serves its purpose if it allows end user devices to directly communicate with each other even if cloud servers with real IPv4 addresses continue to use IPv4 until the end of time.
It serves its purpose if it allows end user devices to directly communicate with each other even if cloud servers with real IPv4 addresses continue to use IPv4 until the end of time.
Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made?
And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
> Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made?
There are known solutions for this.
For host firewalls, the application can open a port for itself during installation.
For network firewalls, the firewall can implement Port Control Protocol (RFC6887), which supports opening even IPv6 ports.
> And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
UPnP is a rubbish fire. The protocol itself is badly designed and unnecessarily complicated and many of the implementations are broken. Section 9 of RFC6886 is informative.
One of the common failure modes is that a client will create a port mapping with a random UPnP device that isn't the real gateway. Many applications will then falsely indicate that incoming connections are working but none ever come through.
And it's still sharing an IP address. Only one device can have the ssh port, or the SMTP port, or any other port.
IPv6 + Port Control Protocol fixes all of that.
There are known solutions for this.
For host firewalls, the application can open a port for itself during installation.
For network firewalls, the firewall can implement Port Control Protocol (RFC6887), which supports opening even IPv6 ports.
> And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
UPnP is a rubbish fire. The protocol itself is badly designed and unnecessarily complicated and many of the implementations are broken. Section 9 of RFC6886 is informative.
One of the common failure modes is that a client will create a port mapping with a random UPnP device that isn't the real gateway. Many applications will then falsely indicate that incoming connections are working but none ever come through.
And it's still sharing an IP address. Only one device can have the ssh port, or the SMTP port, or any other port.
IPv6 + Port Control Protocol fixes all of that.
How much progress is simply due to mobile? Not a bad thing, but legacy ISPs seem to be updating at a glacial pace.
Comcast is one of the leaders in this space in the US. They are nearing 100% deployment and their X1 platform is supposed to run IPv6 only internally (SetTop Boxes to their content source).
Verizon on the other hand hasn't done shit.
Verizon on the other hand hasn't done shit.
My Verizon Wireless iPhone has a v6 address. Maybe you mean FIOS?
It's not, alas, a flip-a-switch upgrade, given how many CPEs and other equipment have shoddy or non-existent IPv6 support.
Forward-thinking network operators (like Verizon Wireless or Comcast or T-Mobile USA) have taken advantage of the LTE and DOCSIS 3 transitions (which inherently involve installing and provisioning new hardware on a massive scale) to properly provision and deploy IPv6 to their customers.
There's plenty of large eyeball networks (https://www.akamai.com/uk/en/about/our-thinking/state-of-the... , click on "Networks" to sort by traffic volume, the second column is the percentage of requests from that network via IPv6) that have working IPv6 deployed and used to a significant percentage of their subscribers -- some around 80%.
Forward-thinking network operators (like Verizon Wireless or Comcast or T-Mobile USA) have taken advantage of the LTE and DOCSIS 3 transitions (which inherently involve installing and provisioning new hardware on a massive scale) to properly provision and deploy IPv6 to their customers.
There's plenty of large eyeball networks (https://www.akamai.com/uk/en/about/our-thinking/state-of-the... , click on "Networks" to sort by traffic volume, the second column is the percentage of requests from that network via IPv6) that have working IPv6 deployed and used to a significant percentage of their subscribers -- some around 80%.
The CPE problem is a bit of an elephant in the room. Just from my own experience, setting up IPv6 on my Comcast connection took quite a bit of fumbling around before I managed to hit on the right settings - and my router's GUI hardly even acknowledges the existence of IPv6 at all.
On the upside, I have a /60 to play with...
On the upside, I have a /60 to play with...
This is really hit or miss (the configuration part of it) and it won't become really ubiquitous until it gets enabled on all consumer CPE by default. That said, I set up a recent Asus for a friend and it was nearly single-click easy on Comcast. Much improved since even 18 months ago.
This is also why ISP's prefer to rent you CPE and (preferably) manage it remotely.
This would in turn cause more content networks to support ipv6 - once even 1% of eyeballs can't hit revenue producing websites those customers will demand v6 or move IaaS/SaaS/etc. providers.
This is also why ISP's prefer to rent you CPE and (preferably) manage it remotely.
This would in turn cause more content networks to support ipv6 - once even 1% of eyeballs can't hit revenue producing websites those customers will demand v6 or move IaaS/SaaS/etc. providers.
The CPE problem is why mobile has such good IPv6 deployment (along with the LTE people having their act together about IPv6) -- it's the only sector where people will eagerly upgrade their CPEs en masse :)
I know that for many years the eyeball networks in the US were dragging their feet in their IPV6 rollouts but I believe this has changed dramatically. Spectrum(Time Warner) states 90% of residential[1] is now on IPV6 and Comcast was at 30% 4 years ago[2]:
[1] https://www.timewarnercable.com/en/support/internet/topics/i...
[2] http://corporate.comcast.com/comcast-voices/comcast-reaches-...
[1] https://www.timewarnercable.com/en/support/internet/topics/i...
[2] http://corporate.comcast.com/comcast-voices/comcast-reaches-...
Charter/Spectrum is actively rolling out IPv6 to customers now:
http://www.spectrum.net/support/internet/ipv6-faq/
[deleted]
I now receive a block of IPv6 from Comcast. I allow the router to assign them to devices on the network, but I admit that I am somewhat worried that my local PC is no longer isolated from the Internet by a private IP.
You want to set up an 'egress only' v6 gateway for your /64s (or however you carve up your netblock). That is going to be the closest analogue to behind-a-NAT-like behavior.
Thanks I'll look into it with pfSense.
Your router has a firewall, external computers can't just send packets to the internal addresses. NAT is not a firewall.
So IPv6 firewall rules are common now for consumer routers?
Yes.
My mum's boring broadband connection, with a free router supplied by the ISP in the UK, has the functionality next to the port forwarding settings for IPv4.
That's typical. Look up IPv6 pinhole to see how ISPs document it.
My mum's boring broadband connection, with a free router supplied by the ISP in the UK, has the functionality next to the port forwarding settings for IPv4.
That's typical. Look up IPv6 pinhole to see how ISPs document it.
OK, so I suspect that it varies greatly among markets.
But I wonder, is it a fair assumption that the router that you get will either 1) not route IPv6 at all, or 2) route IPv6, and by default deny incoming traffic? Problematic would be ones that routed IPv6, and by default accepted incoming traffic.
But I wonder, is it a fair assumption that the router that you get will either 1) not route IPv6 at all, or 2) route IPv6, and by default deny incoming traffic? Problematic would be ones that routed IPv6, and by default accepted incoming traffic.
First, nothing is common for consumer IPv6 routers, they're practically non-existent.
Second, you get the same security benefits by having a firewall that denies outbound connections not already established.
Second, you get the same security benefits by having a firewall that denies outbound connections not already established.
I bought an IPv6 router 3-4 years ago.
Most people don't buy routers, they are given them by their ISPs. My parents switched ISP at the start of the year and were given a 5 year old modem/router.
You're also on Hacker News. They have been available for a long time, but they're firmly a techie/early adopter product.
In many countries the ISP supplies the router. I've had IPv6 capable routers for years and years in Britain, but it's only in the last 2 years or so that the IPv6 address has been assigned by the ISP.
I think whilst it's nice to have that barrier, it's prevention rather than cure anyway. There's no substitute for secure devices :)
what's more secure than a device you cannot possibly reach?
I'll take an insecure device isolated at the bottom of the ocean in a titanium block over a probably-secure device that is publicly addressable any day.
I'll take an insecure device isolated at the bottom of the ocean in a titanium block over a probably-secure device that is publicly addressable any day.
Your appliance 'router' can (and probably does) run a firewall to give you that kind of control. NAT never really gave you that.
Be sure that you are really isolated if relying on it for protection. Its only as secure as the least secure node inside the bubble, and there can be quite a dangerous in large networks like in a company or campus. It would not surprise me if a number of WannaCry victims was behind nat and got infected by a machine on the same local network.
I was at a company that made a mistake like this during their IPv6 rollout. The firewalls are different an individual, and initially they only had iptables rules on their BGR and an empty ip6tables set.
This is the case for ipv6 on mobile data by default. Would using a usb modem result in getting affected by smb exploits or something of the sort?
[deleted]
I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html
EDIT: Dan has many excellent points, but I'd like to quote my favorite:
The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
Indeed, what were they thinking!
It's certainly an undeniable fact that IPv6 adoption has been a disaster, taking much longer than hoped for. Frankly, I expect to see IPv4 coexist with IPv6 for the next hundred years - not ideal.
EDIT: Dan has many excellent points, but I'd like to quote my favorite:
The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
Indeed, what were they thinking!
It's certainly an undeniable fact that IPv6 adoption has been a disaster, taking much longer than hoped for. Frankly, I expect to see IPv4 coexist with IPv6 for the next hundred years - not ideal.
> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
I respect djb and his contributions to cryptography, but he is off base here. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space.
Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.
IPv6 has lots of flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, etc.) that only looked good in the 90s, that definitely made ipv6 adoption a lot more painful than it needed to be, and ended up as difference for just difference's sake; but the one thing that was unambiguously done right with v6 was a completely clear separation of address spaces from IPv4.
I respect djb and his contributions to cryptography, but he is off base here. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space.
Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.
IPv6 has lots of flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, etc.) that only looked good in the 90s, that definitely made ipv6 adoption a lot more painful than it needed to be, and ended up as difference for just difference's sake; but the one thing that was unambiguously done right with v6 was a completely clear separation of address spaces from IPv4.
I think anyone who thinks DJB's proposal was a realistic easy option needs to look at the history of the class E address space (240.0.0.0/4), and the proposals to allocate it for normal use.
Despite not changing the address length at all, the idea of doing this was abandoned because of the widespread compatibility problems across different OSes.
Sure, you could hand-wave another layer of NAT to "fix" it, just like the extended address proposals.
Hell, even using MAC addresses which begin with a number devices haven't seen before is enough to cause issues, despite following the existing standards: https://news.ycombinator.com/item?id=13090945
And all the existing NAT / firewall / middleware devices - they're supposed to handle the extensions transparently? Having seen the many ways that ASA protocol / application fixup can mangle packets - I find it very hard to believe.
Despite not changing the address length at all, the idea of doing this was abandoned because of the widespread compatibility problems across different OSes.
Sure, you could hand-wave another layer of NAT to "fix" it, just like the extended address proposals.
Hell, even using MAC addresses which begin with a number devices haven't seen before is enough to cause issues, despite following the existing standards: https://news.ycombinator.com/item?id=13090945
And all the existing NAT / firewall / middleware devices - they're supposed to handle the extensions transparently? Having seen the many ways that ASA protocol / application fixup can mangle packets - I find it very hard to believe.
One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other? Or two computers with extended addresses, but with a single router in the middle of their path which doesn't understand extended addresses?
All these proposals I've seen appear to assume that extended addresses start being distributed only after every or almost every host and router in the whole world had all of its software upgraded to understand extended addresses. But that's not realistic, since without being able to actually use it, there would be no incentive to modify every single piece of network-facing software and hardware to be able to use extended addresses. It's a Catch-22.
All these proposals I've seen appear to assume that extended addresses start being distributed only after every or almost every host and router in the whole world had all of its software upgraded to understand extended addresses. But that's not realistic, since without being able to actually use it, there would be no incentive to modify every single piece of network-facing software and hardware to be able to use extended addresses. It's a Catch-22.
There are two issues in migration: updating software and updating configuration. The former can be completely trivial if you are just pulling down updates from someone else. The latter requires effort on your part. If the IPv6 address space had been an extension, then you wouldn't have to do any configuration to support IPv6 clients while you maintain your existing 32-bit address, valid for both stacks.
At least that's my understanding of it.
At least that's my understanding of it.
For a new transport layer protocol like QUIC, this can work. However when you start talking about IP, you need to update/replace basically every device on the internet. If a device in the path doesn't know about the extended address space, that packet probably can't reach it's destination.
? You have to upgrade the software on all devices to move to a larger address space. That's understood. What we are discussing here is the added complexity of the configuration. Updating the software is easy by comparison.
> One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other?
Via a NAT router that talks v4 on one side and v6 on the other.
Via a NAT router that talks v4 on one side and v6 on the other.
A NAT router is not enough. Suppose the v4 side wants to initiate the communication; to which address would it send the initial packet? Remember, the "v4 side" has no concept of extended addresses at all, for it every address must be 32 bits and nothing more. And it also doesn't solve the "v4 router in the middle of the path" problem.
> A NAT router is not enough. Suppose the v4 side wants to initiate the communication.
The router would also need to act as a DNS server and translate v6 responses into dynamically assigned v4 addresses. Routers routinely do this sort of thing today for captive portals.
The router would also need to act as a DNS server and translate v6 responses into dynamically assigned v4 addresses. Routers routinely do this sort of thing today for captive portals.
v4 systems can only talk to other v4 systems.
If there's a system that has only v4, it can tunnel v6 packets out to a tunnel gateway that will unwrap and forward them.
There are other protocol-specific tricks, like v4 DNS records that resolve to a HTTP reverse proxy, which forwards based on hostname and path to the real v6 server, while the v6 DNS records point directly to the v6 server.
If there's a system that has only v4, it can tunnel v6 packets out to a tunnel gateway that will unwrap and forward them.
There are other protocol-specific tricks, like v4 DNS records that resolve to a HTTP reverse proxy, which forwards based on hostname and path to the real v6 server, while the v6 DNS records point directly to the v6 server.
> v4 systems can only talk to other v4 systems.
That depends on what you mean. A v4 packet can only be delivered unaltered to a v4 stack. But one can build a proxy server that tunnels TCP and UDP from a v4 network to a v6 network, so data can be passed from a v4 system to a v6 system without any software changes at either end.
That depends on what you mean. A v4 packet can only be delivered unaltered to a v4 stack. But one can build a proxy server that tunnels TCP and UDP from a v4 network to a v6 network, so data can be passed from a v4 system to a v6 system without any software changes at either end.
If you assume that IPv6 adoption is only due to IPv4 address shortage, then the rate of adoption makes a lot of sense. Whatever alternative to IPv6 you can come up with, as long as there is plenty of IPv4 space, nothing will happen. Unless you can find a killer app in a different area, which hasn't happened.
Now that you have to buy IPv4 addresses at around $10 for a single address, the game has changed.
With carrier grade NAT, content has to slowly migrate to IPv6 for geo-location reasons. Any content that sees a high amount of abuse also has to avoid CGN.
Once big parties like google, facebook, etc. have a lot of traffic on IPv6, it stops making sense for them to invest in IPv4. So they will try to pressure ISPs into offering IPv6. Likewise, if an ISP sees that big content providers are on IPv6, then it stops making sense to invest in IPv4. Pressuring smaller content providers to offer IPv6.
And then IPv4 joins the ranks of IPX, NetBIOS, Apple Talk. Some pockets may continue to exists, but the rest of the world has moved on.
Now that you have to buy IPv4 addresses at around $10 for a single address, the game has changed.
With carrier grade NAT, content has to slowly migrate to IPv6 for geo-location reasons. Any content that sees a high amount of abuse also has to avoid CGN.
Once big parties like google, facebook, etc. have a lot of traffic on IPv6, it stops making sense for them to invest in IPv4. So they will try to pressure ISPs into offering IPv6. Likewise, if an ISP sees that big content providers are on IPv6, then it stops making sense to invest in IPv4. Pressuring smaller content providers to offer IPv6.
And then IPv4 joins the ranks of IPX, NetBIOS, Apple Talk. Some pockets may continue to exists, but the rest of the world has moved on.
IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.
[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/
[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/
The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art.
There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.
The term "crank" (https://en.wikipedia.org/wiki/Crank_(person)) is applicable here.
There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.
The term "crank" (https://en.wikipedia.org/wiki/Crank_(person)) is applicable here.
I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.
Some parts of it are laughable such as
For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.
He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.
Some parts of it are laughable such as
IPv10 support on "all" Internet connected hosts can be deployed
in a very short time by technology companies developing OSs
(for hosts and networking devices, and there will be no
dependence on enterprise users and it is just a software
development process in the NIC cards of all hosts to allow
encapsulating both IPv4 and IPv6 in the same IP packet header.
For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.
He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.
I just spent more time than I should have reading these threads (a bigger and more interesting one starts at https://www.ietf.org/mail-archive/web/int-area/current/msg05...). Fascinating. The author:
- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".
- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.
Edit: the author is now requesting that the internet-draft be removed from the database: https://www.ietf.org/mail-archive/web/ietf/current/msg103018...
- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".
- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.
Edit: the author is now requesting that the internet-draft be removed from the database: https://www.ietf.org/mail-archive/web/ietf/current/msg103018...
DJB's point is certainly valid, but in practice, while I had always shared the opinion that the Big Plan of all those committees to seamlessly migrate to IPv6 seemed a bit sketchy, in reality, it's worked quite well.
Funnily, having worked on adding dual-stack support to several pieces of software and protocols, my main grips with IPv6 remain how addresses are represented to humans. Despite compression and all, I realize there was no obvious way to make addresses easier to memorize and that's basically the price to pay to have a staggering 1'500 addresses per square meter of earth.
However, and it may sound a bit silly but I still consider that the choice of ':' as a separator was an unfortunate one, I'd have a hard time listing all the nasty implications it has in terms of parsing :)
Funnily, having worked on adding dual-stack support to several pieces of software and protocols, my main grips with IPv6 remain how addresses are represented to humans. Despite compression and all, I realize there was no obvious way to make addresses easier to memorize and that's basically the price to pay to have a staggering 1'500 addresses per square meter of earth.
However, and it may sound a bit silly but I still consider that the choice of ':' as a separator was an unfortunate one, I'd have a hard time listing all the nasty implications it has in terms of parsing :)
I was just writing up my own comment to say exactly this when I noticed your comment. It's particularly unfortunate that ipv6 was not made backwards-compatible because it would not have been difficult to do: extra address bits could have been included in the options portion of the header. An IPv4 packet could be routed over an IPv6 network simply by setting the (missing) extended address bits to some canonical default value (most likely 0). The net result would be similar to an HTTP/1.0 client accessing an HTTP/1.1 server with multiple virtual servers running on it: accessing an IPv4 host at A.B.C.D would be the same as accessing an IPv6 host at A.B.C.D.0....0
Such a missed opportunity.
Such a missed opportunity.
That post is incredibly obsolete. In reality, a big chunk of the Internet is already running IPv6 in production as we speak.
That comment is incredibly uninsightful. In reality, the majority of the Internet is still not on IPv6 meaning that you still can't make do (easily) with only an IPv6 connection. Dan's point are true regardless of the adoption rate.
Sure you can - many of us have phones in our pockets right now which are doing just that over LTE.
With an imaginary phone running with an imaginary v4 extended address, you'd still need something in the network at the carrier side to handle communications with legacy devices.
There's not much difference between that and having a v6-only device.
With an imaginary phone running with an imaginary v4 extended address, you'd still need something in the network at the carrier side to handle communications with legacy devices.
There's not much difference between that and having a v6-only device.
When I was at UCLA, I learned this new architecture called NDN https://named-data.net/. It does not rely on addressable device or host. It give addresses to content. Not sure how industry think of this new idea. I watched several talks about NDN. They all have great stories and believe it's the future.
http://named-data.net/doc/NFD/current/manpages/ndn-autoconfi...
Still relies on TCP and UDP and thus still needs IP addresses.
Still relies on TCP and UDP and thus still needs IP addresses.
Corrections: CIDR stands for Classless Inter Domain Routing (because it superseded the Class A/Class B/Class C arrangement, which allowed only three particular allocation block sizes).
I know the author is Spanish; I'd like to point out Orange Spain has been deploying IPv6 addresses to end customers these last weeks using the Dual Stack lite transition system.
All the big ISPs have been testing IPv6 for years now and I'm sure it's just a matter of flipping a switch. Now that a new contender is in town (a 4th ISP) and they're having huge problems because they have no IP addresses left to assign to their customers, I suppose the rest of ISPs will stall even more their transition to IPv6 so they can try and "suffocate" the new ISP.
Just my two cents...
All the big ISPs have been testing IPv6 for years now and I'm sure it's just a matter of flipping a switch. Now that a new contender is in town (a 4th ISP) and they're having huge problems because they have no IP addresses left to assign to their customers, I suppose the rest of ISPs will stall even more their transition to IPv6 so they can try and "suffocate" the new ISP.
Just my two cents...
I've only worked at one company that had full IPv6 support. Even on my current 1GbE fibre setup with a small startup, they still don't have IPv6 rolled out to residents yet. :(
I feel like one big hurdle is IPv6 usability. You can write down and easily remember IPv4 addresses. IPv6 netmasks can get really confusing. They make sense if you expand out every block, but in reality, IPv6 requires a lot of tooling to chop up and work with address spaces in an intuitive way.
I feel like one big hurdle is IPv6 usability. You can write down and easily remember IPv4 addresses. IPv6 netmasks can get really confusing. They make sense if you expand out every block, but in reality, IPv6 requires a lot of tooling to chop up and work with address spaces in an intuitive way.
I love it when people make this argument. The IPv6 adoption hurdle is NOT the usability of v6 addresses. 99% of the world thinks that IPv4 addresses are a horrorshow and would never bother to memorize one or even write one down. They use DNS because they are human beings. The layout of the address behind the DNS they couldn't care less about.
I think you are right, now it would be somehow hard to deny the fact that ipv4 addresses were possible to memorize, ipv6's, quite a bit less so. I agree that it's a non-issue 99% of the time, and the overwhelming majority of lambda users will use DNS anyways - that said, when you don't have DNS, are a sysadmin/engineer or what not, you do feel the pain sometimes :)
I think this is the key point. It's too hard to understand, and adds a lot of what I would consider extraneous and over-engineered guff. People will naturally resist it when what they have, works.
The only thing that needed fixing was the address space (imo, as far as I can see), but if I need to turn it on, I now have to worry about weird routing, special addresses (IPv4 has some, but IPv6 seems to have taken it to a new level), understanding hexadecimal addresses, translation layers etc. What a mess, just extend the address space.
The only thing that needed fixing was the address space (imo, as far as I can see), but if I need to turn it on, I now have to worry about weird routing, special addresses (IPv4 has some, but IPv6 seems to have taken it to a new level), understanding hexadecimal addresses, translation layers etc. What a mess, just extend the address space.
Use DNS. Seriously. We use IPv4 where I work, and we don't use DNS, and it's still a nightmare. There's no good way to refer to a machine, short of an IPv4 address, and that's still painful to speak and hard to memorize.
Life is much easier when you can speak of a machine as "2.dev.awesome-service" (.your-company.com)
Besides, the machines should be ephemeral, and the new ones will likely get new IPs. (Unless you're doing something like EIPs, but just stop that and use DNS. ;-) )
Life is much easier when you can speak of a machine as "2.dev.awesome-service" (.your-company.com)
Besides, the machines should be ephemeral, and the new ones will likely get new IPs. (Unless you're doing something like EIPs, but just stop that and use DNS. ;-) )
[deleted]
If you enjoyed this, this is a great resource current state of prefix utilization in the global routing tables:
http://www.cidr-report.org/as2.0/
http://www.cidr-report.org/as2.0/
IPv4 is like any commodity. Now that it's not easily to get from ARIN, a market has sprung up around buying and selling it.
It's still relatively easy to get IPv4 blocks for a buck or two per IP through auction houses.
It's still relatively easy to get IPv4 blocks for a buck or two per IP through auction houses.
Although whatever block you get has to be big enough to convince people to route to it. Too small and it won't matter. No ISP wants to carry the load for millions of tiny IPv4 blocks.
The smallest you can get is a /24, and everyone accepts routes for that.
In 1997, I remember running 2 T1's w/BGP on a router with a whopping 32 megs of RAM. I think there were 50,000 routes! How things have changed...
In 1997, I remember running 2 T1's w/BGP on a router with a whopping 32 megs of RAM. I think there were 50,000 routes! How things have changed...
Would have been awfully nice to have a reserved bit in hindsight. 7 bit ASCII was an amazing accident. (Maybe it wasn't, time to brush up on my history...)
We do/did! Class E space (240.0.0.0/4) exists and is entirely unused. There was a proposal in 2008-ish to try and convert it to regular IP space for allocation, but the agreement was that it would be too much work (many stacks default drop class E packets) and we should focus on transitioning to IPv6.
Thanks, I wasn't really aware of this. Class E wouldn't add too much to the IP address space if I understand this correctly?
I was thinking more along the lines of a bit being flipped would mean the next 8 bytes are an IP and not four, for example.
From my limited understanding, I don't think they reserved a bit in the address space?
I was thinking more along the lines of a bit being flipped would mean the next 8 bytes are an IP and not four, for example.
From my limited understanding, I don't think they reserved a bit in the address space?
If you're advocating for the introduction of variable-length IP addresses then it would have been a nightmare - packet-switching is often done in hardware and that level of complexity would have only added trouble.
Any harder than implementing IPv6 in hardware? I'm talking about an adjustment that would keep older machines talking to older addresses, whilst newer machines could implement extended IPv4, for example. From my potential ignorance, I'm not sure how that would be more difficult?
I think it's theoretical of course, I don't believe there is a reserved bit in the IPv4 range.
I think it's theoretical of course, I don't believe there is a reserved bit in the IPv4 range.
IANA sold the blocks. There are still a lot of unused IPv4 addresses. IANA sold the blocks.
PS IPv6 sucks.
PS IPv6 sucks.
The IANA blocks were exhausted in January 2011. All of the RIRs save AFRINIC exhausted their internal allocation pools since then: APNIC in April 2011, RIPE September 2012, LACNIC June 2014, and ARIN September 2015 (although note that the definition of "exhaustion" differs from RIR to RIR--ARIN in particularly relied on a truly-bone-dry definition whereas APNIC claimed exhaustion when they had less then a full /8 in their pool).
As of right now, ARIN appears to have exactly 0 IPv4 addresses--they can't even give out a block of 256 IPv4 addresses to someone who asks for it. All they can do is put you on a waiting list until someone else agrees to give up their IPv4 address space. Some people have been waiting since July 2015.
As of right now, ARIN appears to have exactly 0 IPv4 addresses--they can't even give out a block of 256 IPv4 addresses to someone who asks for it. All they can do is put you on a waiting list until someone else agrees to give up their IPv4 address space. Some people have been waiting since July 2015.
[deleted]
We only use 32 bits of each 48 bit ipv4 address. The problem isn't exhaustion, it's using DNS to do service location rather than IP.
If you mean ports, those aren't IP. Those are TCP/UDP.
Also somewhat exasperating that the "running out of IPv4 addresses" saga has played out across almost my entire career. I remember attending the CIDR meetings at the IETF in around 1992, for example. So one of the first technical problems I encountered in my career remains unsolved nearly 30 years later.