AWS IPv4 Estate Now Worth $4.5B(toonk.io)
toonk.io
AWS IPv4 Estate Now Worth $4.5B
https://toonk.io/aws-ipv4-estate-now-worth-4-5-billion/index.html
475 comments
These arguments always boil down to these two:
"Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible.
"Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses.
The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels a need to migrate to IPv6.
E.g.: How many customers would you gain by supporting IPv6? Generally zero. That doesn't sell well internally when the network team is asking for a budget.
The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.
The sudden bit will happen when IPv4 address will cost $1K to $10K annually. At that point, customers will be reaching those IPv4 endpoints via three layers of proxies or NAT gateways, and IPv6 will be noticeably faster, more reliable, and free.
"Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible.
"Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses.
The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels a need to migrate to IPv6.
E.g.: How many customers would you gain by supporting IPv6? Generally zero. That doesn't sell well internally when the network team is asking for a budget.
The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.
The sudden bit will happen when IPv4 address will cost $1K to $10K annually. At that point, customers will be reaching those IPv4 endpoints via three layers of proxies or NAT gateways, and IPv6 will be noticeably faster, more reliable, and free.
There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase.
So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers.
For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today.
IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.
So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers.
For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today.
IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.
This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses.
The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.
The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.
> This is exactly how NAT64 works
No. The NAT64 hack involves intercepting the DNS requests and rewriting the IPv6 packets in flight so that the IPv6 only clients see outside IPv4 hosts as IPv6. Among many issues, it breaks any end-to-end encrypted protocol that includes IP literals, such as FTP and SIP.
Also, NAT64 presents no immediate benefit to a client upgrading in a IPv4 only environment, since it still doesn't allow two clients behind NAT64 gateways to connect to each other if there isn't an IPv6 connection between them. So the same old IPv6 self-fulfilling tragedy, everybody must upgrade before anybody can see any benefit, therefore nobody upgrades (or uses NAT64).
The main benefit of a backwards compatible packet format is that IPv4.1 islands see each other from day one in the legacy IPv4 internet and get the full benefits of the new protocol, without any configuration or tunnels. The "encapsulation" seen by legacy hops is in fact the canonical, definitive packet structure, there is no temporary transition technology that can break or needs to be configured.
> the problem of IPv4 clients trying to connect to servers with only IPv6 addresses
This is not a problem that can or should be solved, and it's not the problem significantly preventing IPv6 adoption. A non-upgraded client will just see an IPv4 internet, just like an USB 1.0 won't be able to use USB 2.0 speeds.
The difference is that, while a software&hardware upgrade to IPv6 won't bring you any new connectivity without extra configuration from your upstream provider, an IPv4.1 upgrade will instantly allow you to see (and connect end-to-end) to all existing IPv4.1 islands and hosts, using only your legacy, IPv4 connection. The hierarchical extended address space (IPv4 subdivisions) is immediately available, incentivizing adoption without risking connection issues, while the upward extended space becomes available when you have a native IPv4.1 connections, just like with IPv6.
No. The NAT64 hack involves intercepting the DNS requests and rewriting the IPv6 packets in flight so that the IPv6 only clients see outside IPv4 hosts as IPv6. Among many issues, it breaks any end-to-end encrypted protocol that includes IP literals, such as FTP and SIP.
Also, NAT64 presents no immediate benefit to a client upgrading in a IPv4 only environment, since it still doesn't allow two clients behind NAT64 gateways to connect to each other if there isn't an IPv6 connection between them. So the same old IPv6 self-fulfilling tragedy, everybody must upgrade before anybody can see any benefit, therefore nobody upgrades (or uses NAT64).
The main benefit of a backwards compatible packet format is that IPv4.1 islands see each other from day one in the legacy IPv4 internet and get the full benefits of the new protocol, without any configuration or tunnels. The "encapsulation" seen by legacy hops is in fact the canonical, definitive packet structure, there is no temporary transition technology that can break or needs to be configured.
> the problem of IPv4 clients trying to connect to servers with only IPv6 addresses
This is not a problem that can or should be solved, and it's not the problem significantly preventing IPv6 adoption. A non-upgraded client will just see an IPv4 internet, just like an USB 1.0 won't be able to use USB 2.0 speeds.
The difference is that, while a software&hardware upgrade to IPv6 won't bring you any new connectivity without extra configuration from your upstream provider, an IPv4.1 upgrade will instantly allow you to see (and connect end-to-end) to all existing IPv4.1 islands and hosts, using only your legacy, IPv4 connection. The hierarchical extended address space (IPv4 subdivisions) is immediately available, incentivizing adoption without risking connection issues, while the upward extended space becomes available when you have a native IPv4.1 connections, just like with IPv6.
1. If you want the solution of IPv4 packets being a subset of the address space of IPv6, your options are rather limited in regards to tampering with the original packet. IPv4 hosts can't deal with the larger addresses of any IPv6 hosts they're talking to.
2. Of course there's no immediate benefit for IPv4 clients - there isn't in your proposal either! It's a compatibility measure, allowing IPv6-only clients to talk to IPv4 servers. (I make that distinction because under no scheme can an IPv4 host initiate a connection to a host with no IPv4 address.)
3. I have no idea what you're talking about with the idea that NAT64 requires IPv4 clients to talk to each other over an IPv6 subsegment. I suspect you're thinking of a different transition technology solving a different problem. NAT64 provides a virtual IPv6 subnet containing the entire IPv4 address space. IPv6 clients can send packets to this subnet, at which point they are routed to the nearest NATting gateway and passed into the v4 internet after packet rewriting.
4. FTP and SIP containing IP literals is an irreducible incompatibility, which cannot accommodate an address size change without intrusive packet rewriting anyway.
2. Of course there's no immediate benefit for IPv4 clients - there isn't in your proposal either! It's a compatibility measure, allowing IPv6-only clients to talk to IPv4 servers. (I make that distinction because under no scheme can an IPv4 host initiate a connection to a host with no IPv4 address.)
3. I have no idea what you're talking about with the idea that NAT64 requires IPv4 clients to talk to each other over an IPv6 subsegment. I suspect you're thinking of a different transition technology solving a different problem. NAT64 provides a virtual IPv6 subnet containing the entire IPv4 address space. IPv6 clients can send packets to this subnet, at which point they are routed to the nearest NATting gateway and passed into the v4 internet after packet rewriting.
4. FTP and SIP containing IP literals is an irreducible incompatibility, which cannot accommodate an address size change without intrusive packet rewriting anyway.
> This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses.
You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
AFAIK, IPv6 adoption is held back by hardware. My ISP doesn't provide IPv6, but its DNS provides IPv6 addresses just fine.
> AFAIK, IPv6 adoption is held back by hardware.
What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two?
T-Mobile was gave a presentation on going IPv6-only in 2017:
> For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64.
* https://www.youtube.com/watch?v=nNMNglk_CvE
So they started in 2007.
Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available.
For the CPE, Free in France had IPv6 in 2007:
* https://en.wikipedia.org/wiki/IPv6_rapid_deployment
What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two?
T-Mobile was gave a presentation on going IPv6-only in 2017:
> For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64.
* https://www.youtube.com/watch?v=nNMNglk_CvE
So they started in 2007.
Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available.
For the CPE, Free in France had IPv6 in 2007:
* https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Maybe my ISP bought T-Mobile's ip4 hardware. Since DNS supports ip6, it suggests software is fine, the only thing left is hardware.
Any hardware router introduced in the last two decades has IPv6 support; in my somewhat outdated experience the barrier to implementation is implementing dual-stack logic in software built for single stack.
ISPs in Belgium implemented IPv6 a decade ago (some even two decades). ISPs elsewhere could have done it too by now (nobody is still using 10+yo hardware, I hope...).
> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase.
That is called DS-Lite and we have it
Still doesn't solve a problem of old clients not being able to access new servers
That is called DS-Lite and we have it
Still doesn't solve a problem of old clients not being able to access new servers
> That is called DS-Lite and we have it
No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user.
The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc.
> Still doesn't solve a problem of old clients not being able to access new servers
See sibling comment on why this is not the right problem to solve either.
No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user.
The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc.
> Still doesn't solve a problem of old clients not being able to access new servers
See sibling comment on why this is not the right problem to solve either.
>”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.”
So… NAT.
So… NAT.
No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing and without translation.
Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
It sounds nice on paper but typically we don't want unsolicited packets to reach internal hosts.
Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
This is solved by statefulness: the router/firewall can be told to drop by default any unsolicited connections.
It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
You won't have the "NAT as a firewall" dilemma because there would be no NAT - this whole thought experiment would take place in the 1996 era, before the explosion of NATs. Expecting your /32 gateway to do any firewalling wouldn't be too different from expecting your ISP to do the same for the entire city at the /18 level.
Is UPnP really unsolicited?
Not really, since in this proposal you'd still have the end-to-end routability that NAT prevents
You can tunnel IPv6 over IPv4 (which is how the very first deployments worked).
And I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4.
> I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4
No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.
A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.
It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.
A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.
It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
Windows actually used to have 6to4 setup by default in the past.
There is no need to manually configure anything since the 6to4 have a globally unique anycast address and the ipv6 space is just derived from the own IP address.
Of course NAT breaks that if used on some box behind the router (also would break your proposal I think?) and there were a few issues with 6to4 (random people running gateways? who deals with abuse?) that lead to the development of 6rd (and which was used by a few fairly large ISPs).
> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase.
Do you mean applying some kind of network address translation?
> So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
Ahem.
Do you mean applying some kind of network address translation?
> So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
Ahem.
[deleted]
The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you).
One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64
Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).
You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.
Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.
One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64
Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).
You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.
Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.
Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.
Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).
When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.
Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).
When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
ipv6 has been around for nearly 30 years.
> Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit.
> That thing is there to stay for 5-10 years, and you just work around it as best you can.
IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
> Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit.
> That thing is there to stay for 5-10 years, and you just work around it as best you can.
IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
> 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
> nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
> nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
If your ISP doesn't support IPv6 today, you should have switched to a competent ISP years ago.
This whole discussion was about what should have been done differently at the start of the IPv6 rollout to help it complete in less than a lifetime, not about the situation some decades in.
But that's what I mean: lots of ISPs have supported IPv6 for 1-2 decades. Most hardware & software already supported it a decade ago, and nobody should be using anything that old without updates. The only reason for an ISP today to not provide it is incompetence.
Two decades ago I was a member of a ISP consumer group, and we discussed it with a couple ISPs back then. They all were working on a planning for it (one smaller ISP even already implemented it back then!). Apparently in other countries ISPs were allowed to behave irresponsibly.
Really, the only way to force such incompetent ISPs out is if governments get involved, or if all/most backbone providers and IX operators set a date where IPv4 will become very expensive, and then one where it will be switched off...
Two decades ago I was a member of a ISP consumer group, and we discussed it with a couple ISPs back then. They all were working on a planning for it (one smaller ISP even already implemented it back then!). Apparently in other countries ISPs were allowed to behave irresponsibly.
Really, the only way to force such incompetent ISPs out is if governments get involved, or if all/most backbone providers and IX operators set a date where IPv4 will become very expensive, and then one where it will be switched off...
> Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster.
This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.
This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.
Don't forget you may need to opt in to get mapping to work. It's not available by default on all platforms.
If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
Sure, that's one line and then you're done. And only if you care about very old (WinXP) or deliberately obnoxious (OpenBSD) platforms.
WinXP implements sockaddr_storage from RFC 2553 - a sufficiently large generic socket address.
But not mapped-v4 sockets; it has independent IPv4 and IPv6 stacks. In any case, hopefully we don't need to write code for it anymore…
> The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you)
The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches.
But Ipv6 features take a few extra bytes and are a problem.
The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches.
But Ipv6 features take a few extra bytes and are a problem.
> But Ipv6 features take a few extra bytes and are a problem.
Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around.
No one pays for the extra free gigabyte that Chrome takes over.
Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around.
No one pays for the extra free gigabyte that Chrome takes over.
> No one pays for the extra free gigabyte that Chrome takes over.
Sure they do. It just doesn’t show up in Chrome’s metrics so Chrome doesn’t care about it.
* Start-up time of other applications. If a program needs 1 GB of RAM, and Chrome is holding all but 512 MB, then the program must perform multiple allocations, waiting for Chrome to release its cache after each one.
* Smaller cache in other programs. Consider a program that can run with 4 MB of RAM, but could use up to 1 GB of RAM to cache intermediate results and improve performance. Such a program would check the amount of RAM available and scale their own cache size accordingly.
* Competing caches in multiple Chrome instances. Multiple independent Chrome instances, such as from Electron shells, each try to cache as much as possible until RAM is exhausted.
Sure they do. It just doesn’t show up in Chrome’s metrics so Chrome doesn’t care about it.
* Start-up time of other applications. If a program needs 1 GB of RAM, and Chrome is holding all but 512 MB, then the program must perform multiple allocations, waiting for Chrome to release its cache after each one.
* Smaller cache in other programs. Consider a program that can run with 4 MB of RAM, but could use up to 1 GB of RAM to cache intermediate results and improve performance. Such a program would check the amount of RAM available and scale their own cache size accordingly.
* Competing caches in multiple Chrome instances. Multiple independent Chrome instances, such as from Electron shells, each try to cache as much as possible until RAM is exhausted.
This concern about an extra few bytes is substantial in approximately zero organizations' IPv6 adoption decisions.
In fact some of the earliest adopters of IPv6 were Google, Microsoft, Netflix. Companies who when you're considering the problem of (N * a few bytes) have a very large N so are the most likely to have material costs from it. Yet even to them, it's a rounding error.
Pedantic note:
For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
The user pays for it or suffers the consequences. Anyone relying on such bloated browsers has externalised the cost for coming up with a resource efficient alternative to their users.
You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
One reason could be the proliferation of prefix delegation, meaning an ISP now controls the numbering of your internal network, and it keeps constantly changing the net block, so you can never get stable local addressing… so you just keep running dual stack or try to use nat66 with a ULA network as a kludge or something.
You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT
However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA.
And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
> IPv6 global address > IPv4 > ULAs.
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.
Source address selection for multiple non-loopback addresses was (maybe still is?) notoriously bad in many OS’s for years.
The only in theory clean alternative to the kludges you mentioned is to let DHCPv6 renumber your network automatically which is a major change in how you have to think about your network.
The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.
> The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment
The existence of fridges with twitter integration proves that there is a need to a Lettice to tweet.
There are all kinds of things that exist, steam-powered motorbike among them. Not all of them exist for the right reasons.
The existence of fridges with twitter integration proves that there is a need to a Lettice to tweet.
There are all kinds of things that exist, steam-powered motorbike among them. Not all of them exist for the right reasons.
One such use case: multi wan routing.
Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?
Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?
IPv6 purists think that you can simple have multiple IP addresses on each client, all configured magically, and reconfigured transparently when your ISP changes, with every device somehow knowing via some form of policy deployment (perhaps via dhcpv6) which network to use for a given flow.
That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s
That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s
There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
NAT works well as an ultra simple firewall. All those ancient IoT devices don’t need to accept traffic from arbitrary addresses, but they may need to communicate with the outside world.
Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
> NAT works well as an ultra simple firewall.
There's something that works even better as an ultra simple firewall: An ultra simple firewall!
> why give an IP to something you don’t want accessible by the outside world?
- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.
- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.
There's something that works even better as an ultra simple firewall: An ultra simple firewall!
> why give an IP to something you don’t want accessible by the outside world?
- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.
- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.
Ultra simple firewalls that expose your internal network architecture are less secure than NAT. You simply cannot information about your internal network without risk and there’s zero direct benefit for doing so.
> There's certainly a requirement for them
Thus proving that ipv6 failed in it's mission to get rid of nat
Thus proving that ipv6 failed in it's mission to get rid of nat
I don't think this is a useful thing to say. If I keep trying to fill up my electric car with petrol, and get so annoyed that it keeps spilling on the floor that I pay someone to install a petrol cap and fuel tank, it would be equally silly to say that electric cars failed in their mission to get rid of petrol use.
There's obviously a need, I didn't deny that. I'm not arguing for ipv6, I just want to learn.
The uses that I found while searching weren't very convincing, I was hoping you could give an example.
The uses that I found while searching weren't very convincing, I was hoping you could give an example.
[deleted]
Network sharing from a device that has only a single IPv6 /128 address comes to mind.
Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be.
Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging.
However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging.
However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
The USB protocols over the wire are generally not compatible between versions, especially at the lowest levels (signalling). That's the definition of how more bandwidth can be squeezed into the same wires. The signalling layer changed between versions.
The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.
Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.
You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.
Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.
You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space?
This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple.
But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
> Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple.
No it is not:
* You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
* You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant.
Basically all the stuff that is happening with IPv6.
No it is not:
* You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
* You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant.
Basically all the stuff that is happening with IPv6.
You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme.
You're re-inventing IPv6.
You're re-inventing IPv6.
No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme.
You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6.
> You could instead move this "port" directly into IP header in backward-compatible way
If you're changing the meaning of the headers, it is by definition not backwards compatible.
You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6.
> You could instead move this "port" directly into IP header in backward-compatible way
If you're changing the meaning of the headers, it is by definition not backwards compatible.
No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it would have been done a long time ago.
Not true. There is Options field to extend IPv4 header. And only server and the router closest to user would need to support such extension, keeping layering violations to minimum.
USB 3 the protocol isn't backwards compatible with USB 2, USB 3 ports just include both USB 2 and USB 3 pins (what one might call dual stack). You can easily connect two differnt devices one to the USB 2 pins and one to the USB 3 pins. If you only want to connect USB 3 devices, there is no need for USB 2 Pins, as done on the PS4.
There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
IPv6 is backwards compatible. In multiple ways:
Option 1: "6to4" https://en.wikipedia.org/wiki/6to4
Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64
Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike)
Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling
Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications)
Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
Option 1: "6to4" https://en.wikipedia.org/wiki/6to4
Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64
Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike)
Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling
Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications)
Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
The fact there are so many options shows the fundamental design problem.
[deleted]
It's iterating over time to fix real problems. No protocol is perfect in the initial RFC.
counterexample: https://datatracker.ietf.org/doc/html/rfc863
RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng)
Section 5.5:
Section 5.5:
CRITERION
The protocol must have a straightforward transition plan from the current IPv4. Category: Informational
Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.Reading, not even trying to understand that list makes my brain explode.
NAT64+DNS64 is the best transition method as it eliminates the need for dual-stack.
Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.
Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.
On hacker news. You're going to find a big contingent of people who are getting things like VPS/colo/dedicated/cloud hosting, only get an IPv6 address on that (or finding that an IPv4 address costs extra) ... and are occasionally finding some customers can't reach their sites without every host having an IPv4 address or paying for something like cloudflare.
So there is a bit of a demand, especially here, for forward compatibility.
So there is a bit of a demand, especially here, for forward compatibility.
What's your problem with the IPv6 end-user experience? Hundreds of millions of end-users are using it without even knowing what an IP is.
the reason for slow IP adoption is that they decided to break all backwards compatibility.
You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc..
if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.
You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc..
if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.
In practice IPv6 is for mass market ISPs and IPv4 is for servers. Wasn’t the intention, but that’s how it is to a first order approximation
There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn
Sorry about that ipv6 committee
There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn
Sorry about that ipv6 committee
> ipv6 is a kind of super NAT that few people bother to learn
true, for now.
sometime it will reverse and i am exited about what will happen in/with the "legacy internet"
true, for now.
sometime it will reverse and i am exited about what will happen in/with the "legacy internet"
"Just extend the address size" was certainly one of the options. Sure, it's still a change, but the point is: After this change, both protocols could have worked side-by-side. Devices that only supported IPv4, no problem, they send 32-bits. Devices that supported IPv6-as-it-could-have been would simply have zero-padded those 32-bits to match the new protocol. Talking to old devices, the zero-padding gets dropped.
That would have saved a lot of pain.
That would have saved a lot of pain.
Then any network address beyond ipv4’s 32 bit range would have been completely inaccessible to any legacy devices. That would have essentially been the same situation that we have now - where ipv6 only services are inaccessible to anyone on an ipv4 network. So service operators need to keep their ipv4 addresses and networks don’t update.
How would that be an improvement over the existing situation?
How would that be an improvement over the existing situation?
No it wouldn't. Think about how that would work for a minute. It would've created nondeterministic routing loops that would be a nightmare to debug.
Everyone is always quick to complain that we're going through N number of NAT gateways or N number of proxies, but this is virtually never a problem for most of the Internet. Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use and love such as VoIP, WebRTC, HTTP(S), DNS, Gaming, Streaming Video, Mobile Apps, etc.
NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.
NAT and by extension CGNAT are the unsung heroes of the Internet.
NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.
NAT and by extension CGNAT are the unsung heroes of the Internet.
>Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use
That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4".
Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers).
>NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience
I think there would be many more that wanted this if it were trivially easy to do
>but there has to be some sacrifice to keep the Internet running for the billions of users.
What's the sacrifice in using IPv6?
That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4".
Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers).
>NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience
I think there would be many more that wanted this if it were trivially easy to do
>but there has to be some sacrifice to keep the Internet running for the billions of users.
What's the sacrifice in using IPv6?
> I think there would be many more that wanted this if it were trivially easy to do
I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs.
> What's the sacrifice in using IPv6?
Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge.
If it were really just a "flip of a switch", everyone would've done it by now.
I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs.
> What's the sacrifice in using IPv6?
Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge.
If it were really just a "flip of a switch", everyone would've done it by now.
In some countries almost everybody already did it. The way they did it is by starting 15-20 years ago, and making sure every new replaced device supports it.
Mobile phones can use a p2p messenger like tox, then they will need to be addressable.
Any kind of application that acts as a server needs a direct IP connection.
Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.
VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.
Smaller newer ISPs that can't obtain one IPv4 address per household are incurring signicant CGNAT costs. https://news.ycombinator.com/item?id=35047624
Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.
BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.
Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.
VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.
Smaller newer ISPs that can't obtain one IPv4 address per household are incurring signicant CGNAT costs. https://news.ycombinator.com/item?id=35047624
Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.
BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.
Most of the applications that could communicate peer-to-peer use relay servers that make delay and scalability worse. Some combinations of NAT may sometimes work without a relay server, but figuring this out is complex and increases connection setup time. Every early SIP/VoIP user had the 'the connection only works in one direction' experience, usually caused by NAT.
A CGNAT is a stateful component which makes it expensive to operate. Failover to a backup is hard, as is scalability with this kind of components. And then there are legal requirements. You have to know what user had which IP address at a given time. I'd rather invest in dual stack instead.
A CGNAT is a stateful component which makes it expensive to operate. Failover to a backup is hard, as is scalability with this kind of components. And then there are legal requirements. You have to know what user had which IP address at a given time. I'd rather invest in dual stack instead.
Peer-to-peer still wouldn't work even in a fully IPv6 world without something like STUN or TURN, since endpoints would still be protected by stateful firewalls preventing external connections to them.
With a firewall, the application knows its public-facing ipv6 address/src port number without STUN. A stateful firewall does not alter packets.
It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either.
What scenario do you have in mind?
It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either.
What scenario do you have in mind?
If the two peers are each behind its own stateful firewall (as would be common with something like BitTorrent), then you still need some 3rd party server accessible to both of them that either relays traffic between them, or at least allows them to negotiate the port pair that they'll communicate on (so that the one which will accept the TCP connection can send a TCP SYN with the other's source port as destination).
The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.
The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.
[deleted]
At this stage it shouldn't require much money to integrate ipv6. Your network equipment needs to be really old to not support v6 natively.
Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.
Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.
> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.
I don't think that's true.
Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done?
There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that.
Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.
I don't think that's true.
Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done?
There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that.
Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.
No, the migration is only done when you're exclusively running IPv6. Very very little of the internet is accessible only over IPv6.
> No, the migration is only done when you're exclusively running IPv6.
I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6.
If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.
I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6.
If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.
What I meant was, almost all server operators on the internet have to support either IPv4-only or dual stack. It is still economic suicide to run an IPv6-only server, at least in most areas of the world. As long as you have to run IPv4 software as well and lease an IPv4 address, I would say you are not fully migrated to IPv6.
"this is an entirely new protocol by the definition "
NO!!!
this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address.
It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP.
The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system.
"The reason for the slow IPv6 adoption is that there was no financial or business pressure."
That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more.
Just add a freaking octet!
NO!!!
this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address.
It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP.
The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system.
"The reason for the slow IPv6 adoption is that there was no financial or business pressure."
That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more.
Just add a freaking octet!
We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload.
Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations.
I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.
Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations.
I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.
You more or less just reinvented a more complicated variant of 6to4/6rd, which is one of the IPv6 transition technologies.
> We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload.
So no router can route it sensibly and no existing client works ? How would that help ?
So no router can route it sensibly and no existing client works ? How would that help ?
Technically address space can be expanded with a reverse proxy like SOCKS5: connect to NAT over ip4 and pass target address or even domain name.
> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.
That's a fresh alternative to the boiling frog metaphor.
That's a fresh alternative to the boiling frog metaphor.
it's probably been mentioned before, but there are customers that require IPv6 (like some US gov agencies and others), so for a lot of B2B/enterprise software companies it actually makes sense to support ipv6. And it's technically interesting, so why not! (I've been there, and it was fun)
Really, IPV6 has failed because of human reasons. I know because almost everyone demonstrably hates it, as evidenced by their behavior.
The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now.
Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least?
I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link:
https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ...
That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god.
Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh.
And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed.
https://en.wikipedia.org/wiki/Internet_Protocol_version_4
Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me.
What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking.
Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling.
I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code.
This is all screaming at the darkness.
The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now.
Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least?
I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link:
https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ...
That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god.
Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh.
And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed.
https://en.wikipedia.org/wiki/Internet_Protocol_version_4
Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me.
What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking.
Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling.
I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code.
This is all screaming at the darkness.
> NOBODY WANTS TO ADOPT IT except by force, even now.
Hi, I've adopted it for many reasons and I'm happy. You'll need to update your count. Seriously though, there's lots of people who adopted it - you'll need some more data for a generalisation like this.
> We have to keep shoehorning apps into 64k ports
With ipv6 you typically get a whole range assigned to your machine rather than a single address. Why expand ports, when you can assign millions of apps to different addresses, with the same port that correctly identifies the service type? As a bonus, this already works with DNS AAAA entries so you don't have to mess with SRV to find the right port.
Hi, I've adopted it for many reasons and I'm happy. You'll need to update your count. Seriously though, there's lots of people who adopted it - you'll need some more data for a generalisation like this.
> We have to keep shoehorning apps into 64k ports
With ipv6 you typically get a whole range assigned to your machine rather than a single address. Why expand ports, when you can assign millions of apps to different addresses, with the same port that correctly identifies the service type? As a bonus, this already works with DNS AAAA entries so you don't have to mess with SRV to find the right port.
You have to go back further in time and hit the designers of IPv4 on the head for not making it forward compatible.
IPv6 is as backward compatible as is possible within this constraint. You can embed IPv4 space within IPv6, there is NAT64, tunneling IPv6 over IPv4 and many other transition technologies. It's not possible to design a protocol that is any more backwards-compatible.
IPv6 is as backward compatible as is possible within this constraint. You can embed IPv4 space within IPv6, there is NAT64, tunneling IPv6 over IPv4 and many other transition technologies. It's not possible to design a protocol that is any more backwards-compatible.
> IPv6 is as backward compatible as is possible within this constraint.
Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html
FWIW I couldn't find the link to that post until finding it on one of the comments here, https://news.ycombinator.com/item?id=33894933 . That whole thread has lots of good commentary.
I still don't understand how people can defend ipv6. I remember the "we better get ready to switch to ipv6" noise a quarter century ago when I started my career. And yet we're still talking about how v4 addresses are worth billions. Ipv6 has been an unmitigated disaster. The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.
Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html
FWIW I couldn't find the link to that post until finding it on one of the comments here, https://news.ycombinator.com/item?id=33894933 . That whole thread has lots of good commentary.
I still don't understand how people can defend ipv6. I remember the "we better get ready to switch to ipv6" noise a quarter century ago when I started my career. And yet we're still talking about how v4 addresses are worth billions. Ipv6 has been an unmitigated disaster. The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.
It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals which looked like today's IPv6 came.
Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6.
Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas.
There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay.
It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.
Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6.
Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas.
There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay.
It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.
> It's not very useful to come 20 years later and re-hash the exact same discussion all over again.
I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:
1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.
2. The insanity of SOAP vs. something like REST.
3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.
Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".
I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:
1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.
2. The insanity of SOAP vs. something like REST.
3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.
Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".
Apart from being very far apart time wise, I don't think the examples are relevant. IPv6 was nothing like that. In several ways, IPv6 is more simple than IPv4. It has constant header size (simplifies routing), the layer busting ARP was reworked into special case of ICMP, global routing rules was vastly simplified (routing table takes less space even if addresses are much larger). And it's telling that during the past twenty years, no one has come up with a more practical deployment scheme.
You can criticize IPsec and mobile IP which was tacked on to the spec. But starting from scratch, a core IP v6 stack is easier to implement than a v4. The TCP parts is downright nasty in comparison.
Most importantly, IPv6 was developed in the open. IETF is the counter example to design-by-committee. That's true today, and that was doubly true twenty years ago.
Every discussion since them mostly concerns resurrecting old ideas about either impractical extensions (misusing port numbers and flags to extend addressing, none of these schemes have been proven practical), more efficient address space allocations (which would have bought us a couple of years, at most) or various ways to tunnel traffic in backwards compatible ways (which is what we did back when 6bone was a thing, but which is not useful anymore).
The mailing lists are completely open. You can join any one of them today, and people did. You can still follow how the discussions went in the archives. Hopefully no one has suggested that IPv6 is the best we can do, but that the process still works and that anyone capable and interested is welcome to attend.
As to whether the industry's obsession with complexity has faded, I bring you Kubernetes.
You can criticize IPsec and mobile IP which was tacked on to the spec. But starting from scratch, a core IP v6 stack is easier to implement than a v4. The TCP parts is downright nasty in comparison.
Most importantly, IPv6 was developed in the open. IETF is the counter example to design-by-committee. That's true today, and that was doubly true twenty years ago.
Every discussion since them mostly concerns resurrecting old ideas about either impractical extensions (misusing port numbers and flags to extend addressing, none of these schemes have been proven practical), more efficient address space allocations (which would have bought us a couple of years, at most) or various ways to tunnel traffic in backwards compatible ways (which is what we did back when 6bone was a thing, but which is not useful anymore).
The mailing lists are completely open. You can join any one of them today, and people did. You can still follow how the discussions went in the archives. Hopefully no one has suggested that IPv6 is the best we can do, but that the process still works and that anyone capable and interested is welcome to attend.
As to whether the industry's obsession with complexity has faded, I bring you Kubernetes.
It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process.
I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes.
That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago.
All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net.
Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything.
There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly.
And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.
I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes.
That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago.
All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net.
Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything.
There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly.
And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.
I don't think that plan is feasible at all.
The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.
Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.
And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.
The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.
The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.
Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.
And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.
The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.
That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients.
This is just not possible.
Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.
Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.
That document is not a proposal, it is a problem statement. It goes without saying that IPv4 only clients - every single one of them - would need to be upgraded in some fashion to support a larger address space. The issue is how to do that while remaining incentive compatible.
The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem.
The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number.
And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.
The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem.
The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number.
And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.
This is a really nice explanation, especially with the phone number analogy, thanks for writing it.
In the UK in the 1990s, all landlines phone numbers were prefixed with a 1, to create space for mobile phones and do on.
Other changes were made in the early days, like the introduction of dialing, then long distance dialing.
Other changes were made in the early days, like the introduction of dialing, then long distance dialing.
IPv6 is adding lots of complexity IPv4 never have to deal with.
SLACC, interface-specific link-local address both look good in paper but cause lots real life headache.
When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.
SLACC, interface-specific link-local address both look good in paper but cause lots real life headache.
When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.
You can use DHCPv6 instead of SLAAC. Plenty of people seem to find SLAAC preferable... and interface-specific link-local addresses are key to making it work so...
> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients.
Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.
Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server)
My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.
How can this work? Well, there are two scenarios:
1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.
2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)
Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.
This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.
Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.
Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server)
My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.
How can this work? Well, there are two scenarios:
1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.
2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)
Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.
This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.
Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works.
The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place?
It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only.
Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it?
The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6.
The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6.
The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only.
If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere.
Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.
If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere.
Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.
I understood djbs article differently then you.
What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."?
But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?
But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?
You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about.
> What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses."
He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address."
You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses.
> maybe I should reread the article a bit more generously and less literally
No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.
> What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses."
He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address."
You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses.
> maybe I should reread the article a bit more generously and less literally
No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.
I have read all of it and I don't agree with you.
But lets roll with your interpretation.
Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.
All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.
So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).
Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.
All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.
So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).
> Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.
Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.
I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:
Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.
The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
.
.
.
Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.
I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:
The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.> I have read all of it and I don't agree with you. But lets roll with your interpretation.
You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.
> even if you magically could keep using the IPv4 address in IPv6 (however that would work)
It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)
> Adding the address to the server is the easiest part of the whole process.
The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].
In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).
[1] https://news.ycombinator.com/item?id=37553377
[2] https://news.ycombinator.com/item?id=37555424
You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.
> even if you magically could keep using the IPv4 address in IPv6 (however that would work)
It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)
> Adding the address to the server is the easiest part of the whole process.
The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].
In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).
[1] https://news.ycombinator.com/item?id=37553377
[2] https://news.ycombinator.com/item?id=37555424
It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.
The problem is the incremental effort (not just software wise, but administrative as well) needed to achieve this outcome. This comment explained it much better than me:
https://news.ycombinator.com/item?id=37555424
Thank you thank you. I feel like this primary point in the post got lost it some of the strawmen of "There is just no way an ipv4 stack could talk to an ipv6 address!"
[deleted]
In this scenario, R sends packets to S over IPv4 only. So S must have an IPv4 address? If S has an address that is larger than 32 bits, what goes in the "destination IP" field in the IPv4 packet that R is capable of sending? If S has an address that is guaranteed to be less than 32 bits then we're just in the IPv4 world.
How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.
How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.
See my reply here, I think it addresses your question: https://news.ycombinator.com/item?id=37556857
> Overall we are now much further into the IPv6 migration than djb ever envisioned.
That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients
I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.
I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/
That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients
I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.
I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/
I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion).
It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?
One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?
One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
I believe the claim is that, IF IPv6 had been a much more minor modification of IPv4, including just a change to the packet structure to have a larger address field, it would have seen more adoption more rapidly than the current version of IPv6 which also changes everything else about the L2-3 stack. Sure, you would have still needed new devices and that would have taken some years, but as long as the network architecture remained the same, it wouldn't have required a quarter century to get to 30% adoption.
I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.
I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.
> which is the only thing people actually wanted from IPv6.
I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.
I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.
Good thing they can benefit from those changes, now that we’re decades in! Can you imagine if they had to manage ARP still?
I don't feel strongly about it, but my reading of the complaint is that the implication is it should've been something like an address in 240.0.0.0/4 plus more bits. Then to IPv4 it looks like a reserved for future use address (and we declare we're done with IPv4 now, there will be no (other) future use) but to (this hypothetical variant of) IPv6 it's a longer address.
I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.
I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.
I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
It's not clear to me how 240/4 would have helped anything.
Or how it would have even be different from a tunneling approach on a high level.
> That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
https://www.google.com/intl/en/ipv6/statistics.html
Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.
https://www.google.com/intl/en/ipv6/statistics.html
Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.
> Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html
It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.
It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.
> It's a dumb post, to the point I think it must be a deliberate troll.
Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.
Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.
Bernstein is known for being very... opinionated.
For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.
For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.
I think that precisely because I don't think he's dumb enough to write a post like that sincerely.
DJB's brilliance at some things doesn't make them immune from saying very silly things about other things.
I'm not saying he's right in all areas, and while it's certainly fine to disagree with his viewpoint, saying his essay "must be a deliberate troll" is laughable nonsense, especially since summarizing "my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is a silly mischaracterization of what djb actually said.
> The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.
Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".
Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".
Vint Cerf has called the decision of it being 32 bits as silly and arbitrary, like having a car odometer with 40 digits. If he had pushed for more, he thought nobody would have taken him seriously.
The idea of 32 becoming scarce was laughable.
Also the complaint about ipv6 isn't a technical one, it's a usability one. Extending it to 48 bits would have been easy enough for people - like international calling.
Those 16 bits could be in hex, as a convention, so something like "(4EA7) 8.8.4.2".
However, I've constantly heard that the 128 bit hexadecimal with colons just looks too complicated and inconvenient.
You might be brilliant and find it easy but to a lot of people ipv6 addresses look like cryptographic hashes
The idea of 32 becoming scarce was laughable.
Also the complaint about ipv6 isn't a technical one, it's a usability one. Extending it to 48 bits would have been easy enough for people - like international calling.
Those 16 bits could be in hex, as a convention, so something like "(4EA7) 8.8.4.2".
However, I've constantly heard that the 128 bit hexadecimal with colons just looks too complicated and inconvenient.
You might be brilliant and find it easy but to a lot of people ipv6 addresses look like cryptographic hashes
If one has to go through the pain of changing everything why not make sure one doesn't have to do it again any time soon?
Also having 64-bit for the network address (and 64-bit for the device) does have certain benefits that make it easier to use than shorter addresses in practice for a single entity, since one can hierarchically model the network and do things like <my_network>:<site-id>:<vlan>. So even in absence of DNS one doesn't quite have to remember 128-bit of information for every device.
Also having 64-bit for the network address (and 64-bit for the device) does have certain benefits that make it easier to use than shorter addresses in practice for a single entity, since one can hierarchically model the network and do things like <my_network>:<site-id>:<vlan>. So even in absence of DNS one doesn't quite have to remember 128-bit of information for every device.
> why not make sure one doesn't have to do it again any time soon?
the pyramids in egypt took over a lifetime to build; a marvel of engineering, as theyve lasted thousands of years and noones had to build replacement pyramids. the problem, though, is noone in todays culture needs pyramids.
the pyramids in egypt took over a lifetime to build; a marvel of engineering, as theyve lasted thousands of years and noones had to build replacement pyramids. the problem, though, is noone in todays culture needs pyramids.
[deleted]
But ever since privacy extensions, that's not how IPv6 is allocated, right? Each individual system is supposed to get a /64. Your household should actually have a /56 or something crazy like that, which few ISPs actually do. SLAAC doesn't even work if it doesn't have it's own /64 per host, I believe.
It is.
A typical enterprise might get allocated a /32, which gives them 32-bit to nicely design their network and give 64-bit to each individual network where devices are connected.
A typical ISP will get allocated a much larger allocation like a /20, which allows them to allocate a /56 for each of their customers while still having a few bits to play with. But all starting with the same <isp_network> prefix.
With IPv4 you will have many separate fragmented networks that have no numbers in common. And this will only get worse over time.
A typical ISP will get allocated a much larger allocation like a /20, which allows them to allocate a /56 for each of their customers while still having a few bits to play with. But all starting with the same <isp_network> prefix.
With IPv4 you will have many separate fragmented networks that have no numbers in common. And this will only get worse over time.
Your initial claim was that a IPv6 address consists of a 64-bit network address, then a 64-bit device address that could be separated into <site-id>:<vlan> as an example.
However, SLAAC demands that each device is given a 64-bit prefix that it then chooses many random 64-bit host addresses from, without any other rhyme or reason. So, if you want to know the IP of a host you want to connect to, you have to remember at least a 64-bit number that changes every day by design. Add to that some extra bits for the particular part of the network you are in.
So your IPv6 is more like <isp-assigned-prefix, 32-56 bits>:<internal-net-prefix, 8-32 bits>:<random-host-address, 64 bits>. Human friendly this is not.
However, SLAAC demands that each device is given a 64-bit prefix that it then chooses many random 64-bit host addresses from, without any other rhyme or reason. So, if you want to know the IP of a host you want to connect to, you have to remember at least a 64-bit number that changes every day by design. Add to that some extra bits for the particular part of the network you are in.
So your IPv6 is more like <isp-assigned-prefix, 32-56 bits>:<internal-net-prefix, 8-32 bits>:<random-host-address, 64 bits>. Human friendly this is not.
> you have to remember at least a 64-bit number that changes every day by design
A machine using IPv6 privacy extensions would have two addresses; one that changes, and one typically based on the MAC address that remains constant.
If you are in the local network with that machine or otherwise are supposed to be in-the-know, you'd know it's fixed address and connect to that.
A machine using IPv6 privacy extensions would have two addresses; one that changes, and one typically based on the MAC address that remains constant.
If you are in the local network with that machine or otherwise are supposed to be in-the-know, you'd know it's fixed address and connect to that.
That's OK if you're directly trying to access the machine, but it's not enough if you're looking through logs to try to understand which of your machines is contacting you.
No it was not. My claim was that the network address part (the first 64-bit) can be separated into <network>:<site-id>:<vlan>.. etc.
I think this is absolutely one of the reasons. Addresses are very hard to remember in ipv6. You usually just have to remember the first 3 parts of ipv4 and then change the last digit based on the host you want. IPv6 I know it has shorthand but still it doesn’t register in my brain the same way.
What alternative do you suggest for making the IP addresses longer (so more people can connect computers to the Internet) while keeping them equally memorable?
The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".
The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".
The problem is that adding so many bits to IPv6 addresses, by way of intended integration of the EUI / MAC address in particular is not actually necessary and is a bit of a mistake. As a rule, no one even wants their MAC address propagated across the entire Internet, nor to be registered in DNS either.
There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by the administrative disadvantages. The protocol could have been designed so that typical layer 3 addresses were not much longer, nor harder to type or remember than IPv4 addresses are.
There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by the administrative disadvantages. The protocol could have been designed so that typical layer 3 addresses were not much longer, nor harder to type or remember than IPv4 addresses are.
IPv6 having 128-bit is a huge advantage for transition. NAT64 shoves the 32-bit IPv4 address into the host field.
MAP-T shoves the source and destination IPv4 addresses and ports into IPv6 address. This makes IPv4-IPv6-IPv4 NAT possible. Which means it is possible to run IPv6-only network with IPv4 at on the customer network and edges.
MAP-T shoves the source and destination IPv4 addresses and ports into IPv6 address. This makes IPv4-IPv6-IPv4 NAT possible. Which means it is possible to run IPv6-only network with IPv4 at on the customer network and edges.
There are certainly advantages as you point out, but just because you have 128 bit addresses does not mean it is convenient for 64 bits of that to be filled with semi-random data.
I don't know why Vint Cerf should or want to take the blame for IP address exhaustion. We knew about the problem for 30+ years, we had a committee in charge of selecting IPng to mitigate such a disaster, we selected IPv6 as IPng, and then we ran out of IP address space. The only reason I could see why Vint Cerf is to have any blame is that he firmly agreed on a clean slate Internet protocol that didn't give any consideration towards a transition plan. Yes that's how the events unfolded, but that doesn't make him some martyr.
Only network engineers should see or care about IP addresses. The fact IPv6 addresses use colons is why people don't use IPv6 is the worst take I've ever heard.
you've /never/ heard anyone call ipv6 long, confusing, and complicated? I've basically /only/ heard people say that.
This is probably because the idealized world of "only network engineers" is leaky. Programmers, sysadmins, people trying to get their network printer to work, non-specialists have to interface with network addresses constantly.
Saying they shouldn't is not a description of reality. Not everyone who needs to set up or diagnose a network do so as a career path.
Almost all hardware and software has supported ipv6 for many many years. The humans using it are the ones that shut it off or disable it. Unless you address the human behavior of why that is, this problem will not be addressed.
I claim there needs to be a friendlier, casual interface that makes people's lives easier. It can be a crude kneecapped sheen so long as it addresses the needs of the general user. Then they'll use ipv6, not for ideology or virtue reasons about the commons but because it makes their lives easier
This is probably because the idealized world of "only network engineers" is leaky. Programmers, sysadmins, people trying to get their network printer to work, non-specialists have to interface with network addresses constantly.
Saying they shouldn't is not a description of reality. Not everyone who needs to set up or diagnose a network do so as a career path.
Almost all hardware and software has supported ipv6 for many many years. The humans using it are the ones that shut it off or disable it. Unless you address the human behavior of why that is, this problem will not be addressed.
I claim there needs to be a friendlier, casual interface that makes people's lives easier. It can be a crude kneecapped sheen so long as it addresses the needs of the general user. Then they'll use ipv6, not for ideology or virtue reasons about the commons but because it makes their lives easier
I've almost never heard anyone in the general population use ip addresses, with the notable exception of gamers, but that's fading away too now that all major games come with friends, parties and deep linking support
I don't really understand the use case for typing up addresses either, copy pasting is going to be more precise, and if one can't read 8 quartet of letters one shouldn't be near networking equipment either.
Heck ibans are about as complex and the general population is coping just fine
I don't really understand the use case for typing up addresses either, copy pasting is going to be more precise, and if one can't read 8 quartet of letters one shouldn't be near networking equipment either.
Heck ibans are about as complex and the general population is coping just fine
right, but this isn't theoretical. ipv6 was finalized 25 years ago and global adoption is around 1/3. There's something seriously wrong and it's not that 2/3s of the world are using Windows Me and 20+ year old devices that don't support it.
It's human and behavior driven and addressing that is a matter of packaging, process, promotion, product, presentation... all those marketing ps.
It's human and behavior driven and addressing that is a matter of packaging, process, promotion, product, presentation... all those marketing ps.
Nitpicking, but it looks closer to 1/2: https://www.google.com/intl/en/ipv6/statistics.html
Also it's increasing at ~5% a year, so in 12 years it'll be at ~104%.
Also it's increasing at ~5% a year, so in 12 years it'll be at ~104%.
Interesting. I guess it depends on how it's measured. I had just searched "adoption rates" and saw it said 1/3.
China is a laggard again here. I earlier saw that they were the largest windows xp holdout left. Sure it's only. 0.5% but many places are down to 0.1.
China is a laggard again here. I earlier saw that they were the largest windows xp holdout left. Sure it's only. 0.5% but many places are down to 0.1.
I host a few video game servers for my friends and love the fact that I can say my easy to remember IPv4 address aloud whenever they forgot it.
I have an IPv6 address but haven't bothered memorizing it or giving it out because it would just be more hassle.
I have an IPv6 address but haven't bothered memorizing it or giving it out because it would just be more hassle.
This is even better:
game.latticeanimal.net. 3600 IN A 1.2.3.4
game.latticeanimal.net. 3600 IN A 1.2.3.4
I don't know a single gamer who rented a domain for private use. In fact, I would argue than the hassle of setting one up is the reason why Hamachi got popular back then. You don't have to bother with knowing any technical stuff, just download a software, share a code and play.
DynDNS was big among some of my gaming friends way back in the 90s at one point, when it was a free, donation-supported tool. It was quite useful and relatively low hassle.
At the time it provided a real simple desktop tool that you would install, sign in to your account name, and it would auto-update a (very) short TTL DNS A record for you. (Generally in the form of username.dyndns.org, but as I recall donators could also bring their own top level domain.)
We've got mDNS today to fill some of that gap, but I still wonder if it would also still be nice to have a "no click" desktop tool in 2023 that could quickly update very short TTL DNS AAAA records for you on a subdomain of your choice, and sort of lament Dyn's many pivots (and eventual Oracle buy out) because that original idea still has legs even if it didn't survive the 90s. (Though maybe this time as a true non-profit internet service or operating system feature.)
At the time it provided a real simple desktop tool that you would install, sign in to your account name, and it would auto-update a (very) short TTL DNS A record for you. (Generally in the form of username.dyndns.org, but as I recall donators could also bring their own top level domain.)
We've got mDNS today to fill some of that gap, but I still wonder if it would also still be nice to have a "no click" desktop tool in 2023 that could quickly update very short TTL DNS AAAA records for you on a subdomain of your choice, and sort of lament Dyn's many pivots (and eventual Oracle buy out) because that original idea still has legs even if it didn't survive the 90s. (Though maybe this time as a true non-profit internet service or operating system feature.)
People used to use https://www.noip.com/ and similar services for this.
Hamachi was popular back in the day because it meant you didn’t need to forward ports on your router. (Something that still confuses some of my friends).
You dont?
It was extremely common with Teamspeak.
It was extremely common with Teamspeak.
But only network engineers pick the protocols used. You’re making life harder for the very people who should be your primary audience.
PS: As a developer, I often read logs and go ”oh yeah, that’s just our satellite office IP”. 192.168.1.110 is the network printer, etc. There’s no hope of recognizing IPv6 addresses at a glance the same way.
PS: As a developer, I often read logs and go ”oh yeah, that’s just our satellite office IP”. 192.168.1.110 is the network printer, etc. There’s no hope of recognizing IPv6 addresses at a glance the same way.
There's more hope than you think as a developer to recognize those types of IPv6 addresses at a glance. The :: shortcut alone also acts a shortcut for pattern matching. You may have network designs where things like {prefix}::110 is the network printer and {prefix}::beef is the cafeteria's new meat printer. Whether or not you bother to remember what exactly {prefix} is or if in worst case it changes regularly and you can mostly ignore it (after briefly pattern matching that it looks close enough to other IPs in your network).
There's different "rules" from IPv4, but as a developer those mostly don't matter and if your network engineer wants you pattern matching your network's machines, then you can just as easily pattern match your network's machines as with IPv4. (That said, there's privacy reasons your network engineers might not want that, security through obscurity and all that. That can be just as true in IPv4, but fewer companies have enough IPv4 address space to truly obfuscate the network patterns. Life is harder for network engineers in IPv6 not entirely because it "has to be" but because "privacy and security is 'easier' if we use a more complicated approach to IPv6 than we did with IPv4 where we would just sequentially number machines within our allotted space".)
There's different "rules" from IPv4, but as a developer those mostly don't matter and if your network engineer wants you pattern matching your network's machines, then you can just as easily pattern match your network's machines as with IPv4. (That said, there's privacy reasons your network engineers might not want that, security through obscurity and all that. That can be just as true in IPv4, but fewer companies have enough IPv4 address space to truly obfuscate the network patterns. Life is harder for network engineers in IPv6 not entirely because it "has to be" but because "privacy and security is 'easier' if we use a more complicated approach to IPv6 than we did with IPv4 where we would just sequentially number machines within our allotted space".)
Maybe if you only have five VMs or something, but when there are 100 or more the additional bits in an IPv6 address will be useful. You can recognize a whole subnet as dev, or production, or a different site, or the office LAN.
Network engineers are the one making the transition (or not).
I can see plenty of situations where colons behaviour might be confusing, let’s start with a http url on a non standard port with credentials embedded, I assume something close to http://01:02@03:04:05:06:07:8000/foo/bar would be a valid url,
Close, it would be more like http://01:02@[03:04:05:06:07:08:09:10]:1112/foo/bar
Great, so now I have to learn a new uri syntax too?
Same syntax, IP just goes in [square brackets] to disambiguate.
$things_i_dont_want_to_need_to_know ++;
> You have to go back further in time and hit the designers of IPv4 on the head for not making it forward compatible.
IPv4 was designed for a handful of research institutions. It is not the fault of the designers that it "escaped" the lab into the 'real world'.
IPv4 was designed for a handful of research institutions. It is not the fault of the designers that it "escaped" the lab into the 'real world'.
NAT64? No what we needed was NAT66, and it took over a decade after IPv4 to deliver this. Because the IPv6 advocates were too opinionated on exactly how IPv6 should work. And since when has the world even agreed to anything even remotely complicated without trying to change things up?
No, NAT needs to be shot into the sun. It's absolutely not needed under IPv6.
I some ideal IPv6-only world, perhaps. But when running a mixed stack like the entire world is right now, it's actually crucial.
Why? It seems useful to hide details of your private network from everyone
You can do that with the privacy extensions. Plus on IPv6 you should get enough address space that it makes no sense to run a scan against anyone.
On IPv4 or NAT there's just 65535 ports to check. On a /48 with privacy extensions there's 2^80 addresses to go through, which from an external point of view don't remain constant. You can't even ping all of that.
On IPv4 or NAT there's just 65535 ports to check. On a /48 with privacy extensions there's 2^80 addresses to go through, which from an external point of view don't remain constant. You can't even ping all of that.
As a end user, my inbound ports are all closed, and I don't care about scanning. But I don't see why everyone should be able to differentiate traffic from my phone from traffic from my laptop so I'm happy that they use the same public IP to connect outside.
Have you ever heard of TCP/IP stack fingerprinting? It is very likely that someone intercepting your traffic can tell apart your phone and your laptop regardless of the originating IP address. Odds are they can even tell your operating systems.
It's not because someone can say whether I'm at home or not by looking at the lights that putting a plate in front of my home saying whether I'm here or not is a good idea ^^ (sorry for the poor metaphor;) )
It's more like that plate is already installed, fully listing the occupants and whether they are home or not, and you are objecting to putting on the lights since people on the street might see you're home.
Anyone who can either man-in-the-middle your traffic or is the intended recipient will be able to do fingerprinting based on your TCP/IP traffic. In addition, a lot of your traffic will likely be HTTP(S), in which case the recipient servers will also be able to set cookies, and perform various additional forms of fingerprinting to learn even more about you. The idea that hiding behind a single IP address gives you any protection is delusional.
Anyone who can either man-in-the-middle your traffic or is the intended recipient will be able to do fingerprinting based on your TCP/IP traffic. In addition, a lot of your traffic will likely be HTTP(S), in which case the recipient servers will also be able to set cookies, and perform various additional forms of fingerprinting to learn even more about you. The idea that hiding behind a single IP address gives you any protection is delusional.
> Can we go back in time and hit the designers of IPv6 upside the head?
Okay we are back in 1992 and are wearing a mullet. 'The Internet' is still a relatively small number of mostly university and government sites, and is barely used for anything important, so a flag day seems pretty feasible.
Okay we are back in 1992 and are wearing a mullet. 'The Internet' is still a relatively small number of mostly university and government sites, and is barely used for anything important, so a flag day seems pretty feasible.
Damn all those "more than anyone could possibly need" guys
Yeah, I never got any of the articles about how well IPv6 is designed. Any article will get me confused about whether an IPv6 address is a range, a computer, a router, or something that points to a resource inside my computer. (I guess it's all of these things?).
But the biggest problems of all: You can write an IPv4 address on a phone call. You might be even able to remember it. Not the case for IPv6, you need to be an expert in Hex and remember the specs design. I can't do it as a developer, I don't think normal people will be able to do it either.
IPv4 is useful because it's just a number (at least from a person's perspective). It works. Just add a letter to it and then you have x26 the capacity.
But the biggest problems of all: You can write an IPv4 address on a phone call. You might be even able to remember it. Not the case for IPv6, you need to be an expert in Hex and remember the specs design. I can't do it as a developer, I don't think normal people will be able to do it either.
IPv4 is useful because it's just a number (at least from a person's perspective). It works. Just add a letter to it and then you have x26 the capacity.
The amount of "account numbers" I have that are in fact alphanumeric with various services suggests that these companies (utility companies, banks, etc.) don't consider this a problem.
One real problem is the friendliness of the numbers allocation.
IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that.
"Well-known" NAT64 prefix: 64:ff9b::
Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006...
=
If problem was allocation, we could have added one number in front: 123.114.123.130.200
Now for backward compatibility:
For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed).
=
A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation"
But now, with all these millions of standards it's such a productivity loss for any tech working in networking.
Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.
IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that.
"Well-known" NAT64 prefix: 64:ff9b::
Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006...
=
If problem was allocation, we could have added one number in front: 123.114.123.130.200
Now for backward compatibility:
If your device, operating system and application are compatible with IPv6, congratulations, you receive 123.114.123.130.200 and talk natively in IPv6.
Otherwise, if you are on an IPv4 device, you receive only a portion of the IP address but from a fake IP starting with 250.x.x.x
inetnum: 250.0.0.0 - 250.255.255.255
organisation: Future use
status: RESERVED
For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed).
=
A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation"
But now, with all these millions of standards it's such a productivity loss for any tech working in networking.
Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.
Things don't need to be backwards compatible, they just need to have a financial incentive attached. That could either come from the market or from the government. There's a cost to making things backwards compatible and this can be avoided if we just don't. There are countless examples of technologies that weren't backwards compatible but happened anyway. For IPv6 the problem is the incentive isn't coming from the anywhere.
IPV6 adoption reminds of the whole Python 2=>3 fiasco except it is much much worse.
IPv4 was made impossible to extend like that. If anyone go bonk them. For making it 4 byte in the first place...
IPv5 tried to stick to 32 bits. That didn't work out: https://www.lifewire.com/what-happened-to-ipv5-3971327
Also, correct me if I'm wrong, but didn't they make the smallest subnet have 64k addresses? I remember a networking teacher say that by that point just ARP traffic will have long killed the subnet.
Yes, if we hit our heads hard enough we can come up with a way to magically put more than 4B addresses in 32 bits. Math and logic don't matter in the real world, only head-hitting does.
Deploy IPv6 and stop grumbling because all the workarounds you spend decades perfecting aren't required anymore.
I personally would have added one additional byte, but when it is written I would have added two bits to each of the original bytes. That has the advantage of making each segment 0-1023. I would have reserved the 1000-1024 values, such that IP addresses look the same visually: 476.188.049.772, but the available number is increased by a factor of more than 200. Maybe it’s not too late to release IPv5…
Engineers/designers never assume their ideas aren’t as clever as it appears in their minds.
Absolutely this. IPv6 is when engineering doesn't face reality and operates on "we know better" standards, when they actually don't know better.
I actually feel antagonist towards the designers for it.
I actually feel antagonist towards the designers for it.
IPv6 is so awful. We need a re-do.
A subtle detail from the article is that address prices peaked in 2021 at $60 and has steadily decreased to $35. Where does it go from here? Is this a proxy for the tech correction?
Ideally the long-term value is $0 when IPv4 becomes irrelevant, but how long that takes, and the prices along the way, are anyone's guess. Even explaining past prices is analogous to stock market voodoo.
Not a fan of ipv6 evangelizing, much less at this point. Just give it up.
What is your solution?
> What is your solution?
Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.
Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.
I mean there's several existing solutions, NAT, ipv4 rationing, ip leasing, coexisting with ipv6.
Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.
I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.
Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.
I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.
Not OP nor a recognised network expert but here is my suggestion:
IPv10. The next IP version number that is unassigned, that is conveniently 4+6.
Basically something that is not breaking compatibility with IPv4 and doesn’t require those dual network stacks nonsense.
IPv10. The next IP version number that is unassigned, that is conveniently 4+6.
Basically something that is not breaking compatibility with IPv4 and doesn’t require those dual network stacks nonsense.
How do you not break compatibility with IPv4 while also getting more bytes in the address?
Maybe just don't? Let it be IPv4 with more bits, the software is already there so dual stacking isn't so bad, adoption might actually be quick if people didn't have to learn much to implement it.
>Let it be IPv4 with more bits
Then it's not IPv4 and is not compatible with IPv4.
Then it's not IPv4 and is not compatible with IPv4.
It'd be compatible (or trivially close) to most of the software that is required to make it work. Which is to say the cost of implementation would be low - not the case with ipv6.
country codes </s>
Well again I’m not a network expert but perhaps we could look at the 240.0.0.0/4 reserved for future use block and add more address bytes in the payload or something. It’s not going to be elegant but IPv6 is kinda elegant and failed.
This is the most hilarious "I don't understand anything about the problem, therefore I don't understand how it's hard" comment I've seen this week.
> perhaps we could look at the 240.0.0.0/4 reserved for future use block
What's the current rate of v4 address space consumption? How long will this block last?
> and add more address bytes in the payload or something.
This is, by definition, not backward compatible.
> perhaps we could look at the 240.0.0.0/4 reserved for future use block
What's the current rate of v4 address space consumption? How long will this block last?
> and add more address bytes in the payload or something.
This is, by definition, not backward compatible.
I may not have been clear enough in my suggestion. The idea would be to use this unused block as a special block. Not to fill it up with normal IPv4 allocations.
See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience.
The problem is indeed hard because no one manage to find a solution at scale since 3 decades.
See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience.
The problem is indeed hard because no one manage to find a solution at scale since 3 decades.
No matter what change you make, or how you make it, if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This is a fundamental and unresolvable problem with "making it backwards compatible"
This is a fundamental and unresolvable problem with "making it backwards compatible"
Wouldn't NAT be an existing and well used solution to this problem?
Even if we accept that NAT is the right solution, it still is pretty limited in how far it has been able to extend the address space, since port numbers only give you two extra bytes of address space. And there are no further extra bytes to stuff somehwere else in a TCP or UDP packet header.
Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.
Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.
Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.
Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.
NAT is the problem that IPv6 fixes. Think about the parent comment
>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.
>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.
> The problem is indeed hard because no one manage to find a solution at scale since 3 decades.
The problem is hard because despite everyone's wishes, it's got nothing to do with technology. All migrations are about economics and incentives, IPv6's qualities as a design (it's a long, long way from perfect, but I'd argue that it's good enough) are irrelevant.
The problem is hard because despite everyone's wishes, it's got nothing to do with technology. All migrations are about economics and incentives, IPv6's qualities as a design (it's a long, long way from perfect, but I'd argue that it's good enough) are irrelevant.
Yah, it certainly seems like maybe that was peak pricing. This write up has some more data on historical pricing https://www.ipxo.com/blog/ipv4-price-history/
I've also heard folks pay quite a bit over the average price for novelty IP addresses, so perhaps that skewed the data? I'd love to be able to buy 2.2.2.0/23 or my favorite 42.42.42.0/24
Yeah, one example is Cloudflare and 1.1.1.1; though the story behind that is less about money and far more interesting. Apparently, APNIC had owned 1.1.1.1 for, basically, forever, but were never able to actually use it for anything because it caught so much garbage traffic. Cloudflare is one of only a handful of service providers that could announce the IP and handle the traffic; so in exchange for helping APNIC's research group sort through the trash traffic, Cloudflare hosts their DNS resolver there.
https://blog.cloudflare.com/announcing-1111/
https://blog.cloudflare.com/announcing-1111/
I would really like to see the results of this research to understand what is going on there.
That’s pretty cool. I’d never though about bogons and debogonizing before, it’s like chasing off all the squatters on your property and more keep coming. You need some fat pipes and beefy servers to be able to handle all the bogus traffic of machines trying to hit your server, and also be able to actually fulfill your purpose.
Make sense now why Cloudflare would be one of the only companies that could handle it!
Make sense now why Cloudflare would be one of the only companies that could handle it!
They only had a 10mbit link. Apparently 50mbit/s was the amount of traffic they received.
Mostly everyone could handle this, not just CloudFlare.
Mostly everyone could handle this, not just CloudFlare.
CloudFlare reported 10Gib/s when they first switched it on. The 10Mb/s link was deliberately limited.
The last public analysis was done in 2010 by RIPE and APNIC. At the time, 1.1.1.0/24 was 100 to 200Mb/s of traffic, most of it being audio traffic. In March, when Cloudflare announced 1.0.0.0/24 and 1.1.1.0/24, ~10Gbps of unsolicited background traffic appeared on our interfaces.
So, what happened to everything that expected 1.1.1.1 to error out and now is getting something?
(not worried about them, just curious)
(not worried about them, just curious)
Yeah it broke my use case. I used to run `curl --retry 9999 http://1.1.1.1` and since it didn't exit, the heat generated by the running curl process kept me warm in the winter. But now http://1.1.1.1 returns immediately, so I'm freezing!
You're obviously a fellow fan of 1172.[0]
[0] https://m.xkcd.com/1172/
[0] https://m.xkcd.com/1172/
I mean, for smaller routers that had static routes set for that subnet, it would probably just keep working - the issue being that trying to get to real addresses in the 1.0.0.0/8 network (or parts of it) wouldn't work.
If you were BGP peering then you'd probably get a real route into your local table though.
So yeah, some stuff would probably have just broken, but that's the risk you take using parts of the IP space you shouldn't be using!
If you were BGP peering then you'd probably get a real route into your local table though.
So yeah, some stuff would probably have just broken, but that's the risk you take using parts of the IP space you shouldn't be using!
Well, a lot of Cisco wireless engineers had to reconfigure their guest wifi captive portals.
Heh :)
To be honest I feel as bad for them as I do for Hamachi, when their (otherwise quite nice in that it was a spiritual predecessor to Tailscale!) overlay VPN service fell apart once 5.0.0.0/24 became publicly assigned.
To be honest I feel as bad for them as I do for Hamachi, when their (otherwise quite nice in that it was a spiritual predecessor to Tailscale!) overlay VPN service fell apart once 5.0.0.0/24 became publicly assigned.
Which is funny because half the time I still end up manually typing 1.1.1.1 and praying for a redirect...
Possibly. It might also have been a bit of a panic because RIPE ran out of IPv4 addresses around that time and it was unclear back then how liquid the transfer market would be.
RIPE ran out in 2012, just after APNIC in 2011.
RIPE had a policy to extremely rate limit allocations from their last /8, which is how they were able to continue allocating for an extra 7 years. The other RIRs had no such policy.
RIPE had a policy to extremely rate limit allocations from their last /8, which is how they were able to continue allocating for an extra 7 years. The other RIRs had no such policy.
IPv6 usage also went up 10% in that time
https://www.google.com/intl/en/ipv6/statistics.html
https://www.google.com/intl/en/ipv6/statistics.html
We should probably consider whether the rent-seeking enabled by the scarcity of IPV4 addresses is one of the things holding back IPV6 adoption.
EU have enough influence to do to IPV6 what it did to USB in iPhones.
It's harder to prove consumer harm with something as abstract as IP addresses, and there's a bunch of other pieces that make this much less unlikely, such as the fact that USBs already become obsolete and need to be replaced, so you're just shifting the replacement cycle.
With all those addresses locked up at the hyperscalers IPv4 has become anticompetitive. So yes, the EU can prove consumer harm.
They don’t need to prove consumer harm to pass laws.
exactly. US anti-trust requires you prove harm to the consumer. In the EU, anti-competitive behavior is enough.
Actually the US gov’t adopted a policy last November to migrate all services to ipv6 by 2025. So the USA might have some weight in the migration.
https://www.ferc.gov/internet-protocol-version-6-ipv6-policy
https://www.ferc.gov/internet-protocol-version-6-ipv6-policy
you mean the fact that amazon has around 4.5B reasons to not support ipv6?
interesting idea
interesting idea
AWS supports IPv6.
https://aws.amazon.com/vpc/ipv6/
https://aws.amazon.com/vpc/ipv6/
Kinda.
2/3 of their internal services don’t. You can do ipv6 only vpc but not if you wanted to use rds or ecr or …
2/3 of their internal services don’t. You can do ipv6 only vpc but not if you wanted to use rds or ecr or …
more like 90% according to
https://awsipv6.neveragain.de/
https://awsipv6.neveragain.de/
Sooner or later any sort of monopoly leads to abuse of power and loss of foresight of greater good.
It should be driving adoption if the capitalists are to be believed.
Make of that what you will.
Make of that what you will.
Hopefully hosting providers putting an actual price on v4 usage will be the push that gets things rolling to v6.
They already do.
An IPv4 costs about 5 dollars per month at current prices.
The cost to own an IP is about $45. But that is almost entirely a one time cost, you can rent an IP for well under $10 a year
How do you do that? I'd like to buy one.
Well, where are you from?
If you are from The Netherlands I can recommend Freedom Internet [1]. A /29 (6 usable IPv4) costs 17 EUR/month (VAT equivalent included). That is less than 3 EUR per IPv4 a month.
[1] https://freedom.nl/diensten/subnet
If you are from The Netherlands I can recommend Freedom Internet [1]. A /29 (6 usable IPv4) costs 17 EUR/month (VAT equivalent included). That is less than 3 EUR per IPv4 a month.
[1] https://freedom.nl/diensten/subnet
You need to buy a minimum of /24
[deleted]
Ah, so $35k then.
most already do, but it's not significant
I don't like this solution because it will cost me money and time to setup myself a modem that can handle properly ipv6 or switch to a more expensive provider.
Send the bill to end users is not what should be done.
All this ipv6 endeavour already cost me a lot of time learning and troubleshooting software, and sometimes realizing that some modems doesn't have a good ipv6 stack and the best solution is to turn it off.
Send the bill to end users is not what should be done.
All this ipv6 endeavour already cost me a lot of time learning and troubleshooting software, and sometimes realizing that some modems doesn't have a good ipv6 stack and the best solution is to turn it off.
Charging for IPv4 is mostly going to affect hosting providers. Until recently, AWS users were charged nothing for public IP so there was no incentive to conserve.
The price for IP for connections is already builtin to the price. Also, ISPs just use CGNAT to share IPs with multiple customers when they are short, It makes sense to charge more for static IP.
How long ago did you do try IPv6? These days it should just work. If your router doesn’t work, get a better router since it is broken.
The price for IP for connections is already builtin to the price. Also, ISPs just use CGNAT to share IPs with multiple customers when they are short, It makes sense to charge more for static IP.
How long ago did you do try IPv6? These days it should just work. If your router doesn’t work, get a better router since it is broken.
Blame your ISP. IPv6 should have already been supported since the 2000s.
Then there are a lot of ISPs to blame: https://www.google.com/intl/en/ipv6/statistics.html
By that chart, the IPv6 rollout will be basically complete by 2030. I suspect it will speed up near the end though as the first few services start to go V6 only.
I mean, that's nice to think about, but are you going to spin up a service that's v6 only?
I sure as hell wouldn't want to be the canary in that coalmine...
I sure as hell wouldn't want to be the canary in that coalmine...
I have a couple on my home network. Since I only have one public IPv4 address, port forwarding only allows me to expose one device on IPv4 on port 80. I could use a reverse proxy for those services, like I do for others, but as the only user who has reliable IPv6 on all my devices, there's no need.
I already do for hobby projects that are only for me and maybe a few friends. Why pay the extra for a v4 address?
That is a really nice chart, thanks for sharing.
What is confusing me is the Netherlands. We only have about 13% adoption. I'm on one of the largest ISPs KPN and get 10/10 on IPv6 tests. Is this because I use a custom router? I'd expect it to be a lot higher since apparently KPN supports IPv6.
What is confusing me is the Netherlands. We only have about 13% adoption. I'm on one of the largest ISPs KPN and get 10/10 on IPv6 tests. Is this because I use a custom router? I'd expect it to be a lot higher since apparently KPN supports IPv6.
Ziggo has also rolled out IPv6 to all its customers so far as I know. They have about 40% of the market.
So I decided to do a bit of research:
* VodafoneZiggo has 40-45% of the home market, but also 25-30% of the business market and 20-25% of the mobile market [1]. They seem to offer IPv6 on their home and business connections, but not on their mobile connections [2, 3, 4].
* KPN (35-40% home/biz, 25-30% mobile): IPv6 for homes (except older modem types) and mobiles, but not by default for businesses [5, 6].
* Odido [ex T-Mobile] (30-35% mobile, 5-10% home/biz): no IPv6 across the board [7, 8].
* Eurofiber (20-25% biz): has IPv6 [9].
* Delta (5-10% home): no IPv6 [10].
* Unspecified smaller ISPs (0-5% home/biz, 10-15% mobile): unknown.
* Finally, a number of wholesale access providers, where the customer presumably has a say in IPv6 support.
This works out to 75-90% IPv6 in homes, 45-60% in businesses (ignoring wholesale) and only 35-45% for mobiles.
So, the mystery is not solved, because this data still doesn’t support Google’s 13% figure…
[1] https://public.tableau.com/app/profile/autoriteit.consument....
[2] https://www.ziggo.nl/klantenservice/internet-wifi/ipv6-bij-z...
[3] https://community.ziggo.nl/t5/Internet/Instellen-ipv6-zakeli...
[4] https://community.vodafone.nl/t5/Archief/IPv6-op-mobiel/td-p...
[5] https://www.kpn.com/service/internet/ipv6.htm
[6] https://zakelijkforum.kpn.com/internet-bellen-9/ipv6-werkt-n...
[7] https://community.odido.nl/bekabeld-internet-492/ipv6-wannee...
[8] https://community.odido.nl/netwerk-en-verbinding-559/wanneer...
[9] https://www.eurofiber.com/nl-nl/snel-internet
[10] https://www.delta.nl/klantenservice/vrije-modemkeuze/, expand ‘stap 4’
* VodafoneZiggo has 40-45% of the home market, but also 25-30% of the business market and 20-25% of the mobile market [1]. They seem to offer IPv6 on their home and business connections, but not on their mobile connections [2, 3, 4].
* KPN (35-40% home/biz, 25-30% mobile): IPv6 for homes (except older modem types) and mobiles, but not by default for businesses [5, 6].
* Odido [ex T-Mobile] (30-35% mobile, 5-10% home/biz): no IPv6 across the board [7, 8].
* Eurofiber (20-25% biz): has IPv6 [9].
* Delta (5-10% home): no IPv6 [10].
* Unspecified smaller ISPs (0-5% home/biz, 10-15% mobile): unknown.
* Finally, a number of wholesale access providers, where the customer presumably has a say in IPv6 support.
This works out to 75-90% IPv6 in homes, 45-60% in businesses (ignoring wholesale) and only 35-45% for mobiles.
So, the mystery is not solved, because this data still doesn’t support Google’s 13% figure…
[1] https://public.tableau.com/app/profile/autoriteit.consument....
[2] https://www.ziggo.nl/klantenservice/internet-wifi/ipv6-bij-z...
[3] https://community.ziggo.nl/t5/Internet/Instellen-ipv6-zakeli...
[4] https://community.vodafone.nl/t5/Archief/IPv6-op-mobiel/td-p...
[5] https://www.kpn.com/service/internet/ipv6.htm
[6] https://zakelijkforum.kpn.com/internet-bellen-9/ipv6-werkt-n...
[7] https://community.odido.nl/bekabeld-internet-492/ipv6-wannee...
[8] https://community.odido.nl/netwerk-en-verbinding-559/wanneer...
[9] https://www.eurofiber.com/nl-nl/snel-internet
[10] https://www.delta.nl/klantenservice/vrije-modemkeuze/, expand ‘stap 4’
Their data must just be out of date. It's been over a year that I've had IPv6 with Ziggo business and home. As you say, Vodafone mobile still only does IPv4 though.
The Ziggo shift would have made a huge impact on the national total.
The Ziggo shift would have made a huge impact on the national total.
Blaming is nice, moving your business elsewhere is better. Unfortunately, not everybody has more than one ISP serving their area.
GitHub.com still doesn't support IPv6. I know that there is some work going on to support it, but this shows that it is far from trivial.
It's usually not a tehnical problem, but either a management or a budget problem.
Hacker news also does not support IPv6
This is one of the reasons why I'm trying to avoid Github these days. If they can't get something as simple as IPv6 to work, I don't have much faith in the test of their backend either.
Sort of a weird take. I doubt if the people responsible for testing their backend have ever even met the people who would migrate to ipv6
There's plenty of attention on the Github meta issue about the lack of IPv6 (https://github.com/orgs/community/discussions/10539) so anyone who even glances at customer requests should be aware of the issue at the very least.
They also did offer IPv6 availability for a short while as a test, but that was quickly shut down, so there is probably a technical issues they can't figure out or they would've kept the trial system running for longer.
Either way, Github isn't communicating, so it's hard to tell if this is indifference or incompetence. As an end user, the distinction doesn't really matter.
They also did offer IPv6 availability for a short while as a test, but that was quickly shut down, so there is probably a technical issues they can't figure out or they would've kept the trial system running for longer.
Either way, Github isn't communicating, so it's hard to tell if this is indifference or incompetence. As an end user, the distinction doesn't really matter.
correct, direct url is https://toonk.io/aws-ipv4-estate-now-worth-4-5-billion/index...
More interestingly, perhaps, is a forward look at how much new revenue AWS will generate once AWS starts charging ($44 per IP per year) as of 2024. I think it's not unlikely that AWS will generate a few hundred million to a billion in additional revenue with this new charge.
I suppose a sufficiently motivated individual could look at something like Shodan, see how many of those IP addresses AWS owns are active (and fudge it by some factor to account for how many of those IP addresses are used by AWS themselves) and multiply it by their new IP address billing.
No need to use Shodan. AWS already publishes the IPv4 address it owns in JSON from a well-known endpoint [0].
[0]: https://ip-ranges.amazonaws.com/ip-ranges.json
[0]: https://ip-ranges.amazonaws.com/ip-ranges.json
AWS does not publish what IPs are active and assigned IE: customers are paying for vs. addresses they own.
What I'm taking from this: switch to IPv6 and you can do a little bit to devalue an asset held by AWS.
Honestly, I've never had such a strong incentive.
Honestly, I've never had such a strong incentive.
Some noob questions here.
How does one buy a block of IPv4 as an individual? (If that's allowed)
After you purchase it, how does it come into your possession?
How do you utilize them?
How does one buy a block of IPv4 as an individual? (If that's allowed)
After you purchase it, how does it come into your possession?
How do you utilize them?
You'll need to become a member of one of the regional Internet route registries, like RIPE or ARIN. Then you can buy, say a /24, and transfer it into your RIPE/ARIN account.
Now you have your own IPv4 range. And you can start for example start to use it for your own servers. To do so you need to "announce" this new /24 to the internet, using a protocol known as BGP. You can do that yourself, using a router, assuming you have an Autonomous system number (AS). You can get these via RIPE or ARIN as well.
Or rely on your hosting provider to do that. For example AWS support "bring your own IP address". In that case they will announce the ip prefix in BGP for you, and you can assign your ec2 instances public IP's out of your range.
Equinix Metal, (previously Packet), also makes it easy to do this.
Before you can "announce" a prefix, you need an ISP willing to peer with you.
BGP is a very insecure protocol. Most of its "security" are enforced by money and contract.
BGP is a very insecure protocol. Most of its "security" are enforced by money and contract.
> BGP is a very insecure protocol.
Take a look at the state of RPKI. ROA validation is common these days, and ASPA validation will be common soon. You still need to manually validate that your peer truly represents the AS that they claim to, but if that's been done, ROA+ASPA validation prevents unauthorized announcements.
Absent RPKI, people have been filtering based on IRR for ages, which will not necessarily prevent unauthorized announcements, but will require an attacker to leave a paper trail when making one.
Take a look at the state of RPKI. ROA validation is common these days, and ASPA validation will be common soon. You still need to manually validate that your peer truly represents the AS that they claim to, but if that's been done, ROA+ASPA validation prevents unauthorized announcements.
Absent RPKI, people have been filtering based on IRR for ages, which will not necessarily prevent unauthorized announcements, but will require an attacker to leave a paper trail when making one.
Thank you for this reply. I learned a lot from it.
> To do so you need to "announce" this new /24 to the internet, using a protocol known as BGP. You can do that yourself, using a router, assuming you have an Autonomous system number (AS).
Is this how BGP hijacking is done?
Is this how BGP hijacking is done?
Technically, yes.
But good ISPs filter the prefixes their customers can announce to only those they actually own.
Then you have shitty providers that dont do it, and thats how you get BGP hijacking.
And you cant do this just from any connection, fyi.
You will need a datacenter, cloud host or residential ISP that actually allows you to peer with them and announce routes. This isnt a standard thing you get just by being a customer.
But good ISPs filter the prefixes their customers can announce to only those they actually own.
Then you have shitty providers that dont do it, and thats how you get BGP hijacking.
And you cant do this just from any connection, fyi.
You will need a datacenter, cloud host or residential ISP that actually allows you to peer with them and announce routes. This isnt a standard thing you get just by being a customer.
I actually went through this process with ARIN. So I can give you that perspective. It wasn't a big deal, the only minor concern I had was it felt like you're encouraged to sign up under a business entity. I had an LLC, so it was natural just to use that. I don't know what kind of vetting they do if you decide to use yourself as an organization though instead of a different legal entity.
You need to provide justification, and frankly it's not that big of a challenge to get a /22 which is what I got. As long as you can show how you would like to use them and over what time frame, they will allow you to go through with the acquisition. An ASN is not required to get any IP block. You can always associate your IPs with any ASN that you want so long as that ASN owner is cooperating with you. I went ahead and grabbed an ASN for ease but some ISPs will allow you to use their ASN.
You also do not have to purchase an IPv4 block from someone. You can go through the normal IPv4 request process, however the waitlist [1] is now over a year long for IPv4. However IPv6 are given out very quickly. IPs you acquire this way are "free" to acquire with your ARIN membership. Your membership dues are determined by the assets you hold, there is a fee schedule [2] and you need to pay it annually to maintain your membership and ASN/IP assignments.
I encourage anyone interested in understanding this process to go through it, it didn't take a ton of time nor did it cost a lot in the grand scheme of things. Being an ARIN member also entitles you to be a part of how IPs are governed in the region you acquired them in. They will occasionally send out surveys and you can vote on issues.
[1] https://www.arin.net/resources/guide/ipv4/waiting_list/
[2] https://www.arin.net/resources/fees/fee_schedule/
You need to provide justification, and frankly it's not that big of a challenge to get a /22 which is what I got. As long as you can show how you would like to use them and over what time frame, they will allow you to go through with the acquisition. An ASN is not required to get any IP block. You can always associate your IPs with any ASN that you want so long as that ASN owner is cooperating with you. I went ahead and grabbed an ASN for ease but some ISPs will allow you to use their ASN.
You also do not have to purchase an IPv4 block from someone. You can go through the normal IPv4 request process, however the waitlist [1] is now over a year long for IPv4. However IPv6 are given out very quickly. IPs you acquire this way are "free" to acquire with your ARIN membership. Your membership dues are determined by the assets you hold, there is a fee schedule [2] and you need to pay it annually to maintain your membership and ASN/IP assignments.
I encourage anyone interested in understanding this process to go through it, it didn't take a ton of time nor did it cost a lot in the grand scheme of things. Being an ARIN member also entitles you to be a part of how IPs are governed in the region you acquired them in. They will occasionally send out surveys and you can vote on issues.
[1] https://www.arin.net/resources/guide/ipv4/waiting_list/
[2] https://www.arin.net/resources/fees/fee_schedule/
I'm curious if one were to be certain nation state and was happy being a completely isolated intranet, that they would just exit such arin or related associations and just create their own governing body of IP allocations? In such a case such an internet would be a completely separate internet right?
I wonder if sanctions may ever apply to the internet itself and we may see a break up of the internet into regional internet's.
And if we want to ensure global connectivity these associations would need to be completely independent and voluntary standard and such fees would be paid to an international standards body not beholden to any particular nation's whims?
What if nations started adding intercontinental NAT gateways acting as the entry and exit points between their national boundaries and the rest of the world.
I wonder if sanctions may ever apply to the internet itself and we may see a break up of the internet into regional internet's.
And if we want to ensure global connectivity these associations would need to be completely independent and voluntary standard and such fees would be paid to an international standards body not beholden to any particular nation's whims?
What if nations started adding intercontinental NAT gateways acting as the entry and exit points between their national boundaries and the rest of the world.
North Korea supposedly has its own intranet with IPs in the 10.0.0.0/8 private range: https://en.wikipedia.org/wiki/Kwangmyong_(network)
I have no idea how they manage IP allocation internally there though.
I have no idea how they manage IP allocation internally there though.
They could just use CGNAT and could get pretty far on that alone. https://en.m.wikipedia.org/wiki/Carrier-grade_NAT
The big nations have already wargamed this scenario and have contingency plans in place.
IMO we'll see this happen in our lifetimes.
IMO we'll see this happen in our lifetimes.
Could starlink be a way to maintain global connectivity in the face of government control? Would they try to jam satellite connections?
It's harder to jam Starlink than GPS because the signals are directional, but if a government doesn't want you using it, they can just make the dishes illegal and throw you in prison for having one.
Starlink is under USA jusrisdiction, as far as I know.
I'm pretty sure there's no concept of "international waters" for communication satellites.
AFAIK Most of the traffic goes: subscriber <-> (single) satellite <-> local base station. And the latter operates under the rules of given country.
Is there a way to get a /24 block that I own and has been unused since the mid 90's routed without signing a new contract and paying the new ARIN fees?
You can not "own" a /24 block. And if your membership lapses, then your blocks are returned to the general pool.
It's possible that your block is a part of a legacy allocation, they are governed differently.
It's possible that your block is a part of a legacy allocation, they are governed differently.
That's exactly why I don't want to sign a new agreement. I have never paid fees for my /24 block that I have held for 30 years.
> block that I own and has been unused since the mid 90's
This timeline suggests that it's still a legacy allocation. The new governance structure does not apply unless you sign an RSA or LRSA agreement with ARIN.
This timeline suggests that it's still a legacy allocation. The new governance structure does not apply unless you sign an RSA or LRSA agreement with ARIN.
You'd be under the LSRA fee schedule.
https://www.arin.net/resources/fees/fee_schedule/#legacy-reg...
So you won't be subject to the new fee structure.
If you want to route then you will need an ASN and an ISP willing to announce them. So long as you are up on your LSRA dues I don't see how you won't be able to utilize them.
https://www.arin.net/resources/fees/fee_schedule/#legacy-reg...
So you won't be subject to the new fee structure.
If you want to route then you will need an ASN and an ISP willing to announce them. So long as you are up on your LSRA dues I don't see how you won't be able to utilize them.
You don't need to sign an LRSA to use the prefix; there are some legacy holdouts still using their original prefixes without any agreement or fees with ARIN. Signing an LRSA will give you access to ARIN IRR/RPKI/rDNS/etc services, which can be quite useful, though.
I'm a holdout and have no desire to sign an LSRA.
I'd recommend creating an IRR route object for your prefix and ASN on AltDB (or finding a sponsor to do so on your behalf). Once you have that in place, you should be able to announce it without issues, without any ARIN involvement. Growing adoption of RPKI filtering may make this increasingly difficult in the future, though.
Thanks for the information.
1. You most likely can't. You typically need to prove to a numbering authority that you need that many IPs (minimum /24) for X reason and you will be multihomed (connected to two+ ISPs) by Y date.
2. You are assigned a BGP Autonomous System Number (ASN) as part of the process. The IPs are assigned to your ASN.
3. You sign a peering contract with ISPs and peer with them using BGP on your router. You use your ASN to announce your block to have traffic routed to/from your router.
One of the tragedies of IPv6, IMO, is not having a better/streamlined process for end users to get allocations without all the red tape. There's tons of space, let's pretend it's the 90s and give away IP blocks to whoever asks. Either require ISPs to give static allocations or make it easier for getting a personal block. No, prefix delegation is not good enough.
2. You are assigned a BGP Autonomous System Number (ASN) as part of the process. The IPs are assigned to your ASN.
3. You sign a peering contract with ISPs and peer with them using BGP on your router. You use your ASN to announce your block to have traffic routed to/from your router.
One of the tragedies of IPv6, IMO, is not having a better/streamlined process for end users to get allocations without all the red tape. There's tons of space, let's pretend it's the 90s and give away IP blocks to whoever asks. Either require ISPs to give static allocations or make it easier for getting a personal block. No, prefix delegation is not good enough.
>One of the tragedies of IPv6, IMO, is not having a better/streamlined process for end users to get allocations without all the red tape. There's tons of space, let's pretend it's the 90s and give away IP blocks to whoever asks. Either require ISPs to give static allocations or make it easier for getting a personal block. No, prefix delegation is not good enough.
This is by design. If we let arbitrary routings of /64 blocks pollute the global routing table shit is going to go sideways as the rest of the net scales up and up. We made that mistake with IPv4 and the only reason our routers haven't gone thermonuclear keeping up with the announced routes is we literally ran out of address space.
We're not going to get the IPv6 equivalent of IPv4 /24s announced ever again. While minimum prefix lengths aren't hard enforced (yet), unless you have the means/reason to be multihomed using /48s you're pretty much going to be under the hierarchical routing of your transport or last mile provider.
This is by design. If we let arbitrary routings of /64 blocks pollute the global routing table shit is going to go sideways as the rest of the net scales up and up. We made that mistake with IPv4 and the only reason our routers haven't gone thermonuclear keeping up with the announced routes is we literally ran out of address space.
We're not going to get the IPv6 equivalent of IPv4 /24s announced ever again. While minimum prefix lengths aren't hard enforced (yet), unless you have the means/reason to be multihomed using /48s you're pretty much going to be under the hierarchical routing of your transport or last mile provider.
Prefix delegation naturally follows physical hierarchy, keeping routing tables compact.
Mandating something like a static /56 (physical location locked) to be available at no extra cost if the customer asks for it, would work fine, though. I'd even accept requiring this only for contracts that allow more than one customer device to access the Internet simultaneously. Yes, a phone plan with two SIMs on one contract would already trigger this.
Mandating something like a static /56 (physical location locked) to be available at no extra cost if the customer asks for it, would work fine, though. I'd even accept requiring this only for contracts that allow more than one customer device to access the Internet simultaneously. Yes, a phone plan with two SIMs on one contract would already trigger this.
It's a little tricky - the more unique v6 allocations we have, the more complex routing gets, and the more resources it needs.
Having a ton of people/businesses with their own announced and unaggregatable /48s would add a lot of entries to routing tables.
Having a ton of people/businesses with their own announced and unaggregatable /48s would add a lot of entries to routing tables.
> 1. You most likely can't. You typically need to prove to a numbering authority that you need that many IPs (minimum /24) for X reason and you will be multihomed (connected to two+ ISPs) by Y date.
If you're asking for a minimum sized range, you don't have to justify more than one ip. It's not super hard to find somewhere where you can be multihomed either, although it's unlikely to be at your home. (Maybe ask isn't exactly the right verb, assuming ARIN/RIPE are out of addresses, you're asking for them to process a transfer that you paid/will pay the current responsible party for)
If you're asking for a minimum sized range, you don't have to justify more than one ip. It's not super hard to find somewhere where you can be multihomed either, although it's unlikely to be at your home. (Maybe ask isn't exactly the right verb, assuming ARIN/RIPE are out of addresses, you're asking for them to process a transfer that you paid/will pay the current responsible party for)
There is still some anxiety about the size of the global routing table. Handing out IPv6 prefixes for free would make the growth much harder to control. (Not that there is much control beyond RIR membership fees.)
Also, there is no organization that can require anything of an ISP’s addressing plan. The IETF and the RIRs are associations, not governing bodies.
Also, there is no organization that can require anything of an ISP’s addressing plan. The IETF and the RIRs are associations, not governing bodies.
> Either require ISPs to give static allocations
Just buy service which does what you actually want - rather than insisting it should be mandatory which means everybody has to pay for it. I have static allocations (both IPv6 and, very small, IPv4) because I care. Most people don't care.
Just buy service which does what you actually want - rather than insisting it should be mandatory which means everybody has to pay for it. I have static allocations (both IPv6 and, very small, IPv4) because I care. Most people don't care.
[deleted]
Speak to the local RIR[1]. They have varying requirements, but broadly you generally need to justify your use case, multi-home (for your own AS) and pay a yearly membership fee. After that, you need to speak to your ISP about either advertising it or peering with you - or going dark fibre if you're a real masochist.
Good luck, update us if you do it!
1. https://en.wikipedia.org/wiki/Regional_Internet_registry
Good luck, update us if you do it!
1. https://en.wikipedia.org/wiki/Regional_Internet_registry
Yeah usually you won't be able to buy one if you don't have your own AS
In my area, the AS is usually provided 'free' with your membership.
fwiw, ATT charges me $15 for ~8 fixed ipv4 addresses on my gigabit plan. Even if we amortize against the total monthly bill of $113, we get ~$15 per IP.
EDIT: I guess this is the cost to _rent_ an IP per month and not the cost of _owning_ an IPv4 address.
EDIT: I guess this is the cost to _rent_ an IP per month and not the cost of _owning_ an IPv4 address.
My ISP has one of the better options where you can permanently lease an IPv4 address for a deposit of $100 AUD. The lease is indefinite, and when you don't want it any more you get the $100 back.
It's great that AT&T offers static IPs, but I should charge them about $600 for my time because it took me 3.5 hours of playing games with the automated support line and explaining to their tech support what static IP addresses are, and that it doesn't matter "what version of Windows my servers are running."
Right. I pay about 50 Euro cents per month for each of mine, so my provider gets about $10 a year let's say. Which means they'll pay for themselves in 3 years on average, after that it's all profit, assuming they are still useful.
At some point. At SOME point, IPv6 will work in enough situations that we can ignore the small minority of situations where it doesn't. If even 90% of the visitors to my web sites could connect on IPv6 I would change tomorrow, but it just isn't that high yet.
At some point. At SOME point, IPv6 will work in enough situations that we can ignore the small minority of situations where it doesn't. If even 90% of the visitors to my web sites could connect on IPv6 I would change tomorrow, but it just isn't that high yet.
I'm paying $100 a month for a /27. So I can assign a real IPv4 to my smart fridge! I might even do that one day, before throwing it out.
$30 for a /27 on ATT. Totally worth it.
What do you use for?
I have 5gbit fiber from ATT and self host all my services
What sort of stuff do you do to make sure those are services hardened? And what kinds of services? I've been meaning to create such a setup, but am a bit concerned about vulnerabilities.
Does the cost of migrating to IPv6 exceed the cost of buying up large swaths of IPv4 addresses?
Question for the networking folk here. How can the rest of us help move things over to ipv6?
If your ISP provides the ipv6 option but doesn't turn it on by default, turn in on. If they don't call them periodically and ask for IPv6 support.
If you run only online service, enable ipv6 on it.
Basically, help move the needle on the chicken and egg issue of adoption. Move more traffic to v6 as much as you have control over.
If you run only online service, enable ipv6 on it.
Basically, help move the needle on the chicken and egg issue of adoption. Move more traffic to v6 as much as you have control over.
To add to this:
Most content distribution networks (CDNs) support IPv6 even if the back-end is IPv4. For most web sites, a CDN is a good idea in general, so just use one.
For developers: don't hard-code IPv4 as an assumption. E.g.: don't validate network addresses with an IPv4-only regex, and don't store addresses into a 32-bit unsigned integer. Most SDKs and APIs have supported IPv4/IPv6 dual-mode addresses for like... two decades by default. Just don't... undo... all that effort!
Generally: Use DNS instead of IP addresses. Do it properly by respecting TTLs and using multiple upstream DNS servers in a fast failover configuration. This is not the default in many systems, especially Linux distros used in servers. Many admins "prefer" raw IP addresses because they think "DNS is unreliable". It isn't, it's just the default config that's poor.
Most content distribution networks (CDNs) support IPv6 even if the back-end is IPv4. For most web sites, a CDN is a good idea in general, so just use one.
For developers: don't hard-code IPv4 as an assumption. E.g.: don't validate network addresses with an IPv4-only regex, and don't store addresses into a 32-bit unsigned integer. Most SDKs and APIs have supported IPv4/IPv6 dual-mode addresses for like... two decades by default. Just don't... undo... all that effort!
Generally: Use DNS instead of IP addresses. Do it properly by respecting TTLs and using multiple upstream DNS servers in a fast failover configuration. This is not the default in many systems, especially Linux distros used in servers. Many admins "prefer" raw IP addresses because they think "DNS is unreliable". It isn't, it's just the default config that's poor.
I’ve been hearing about ipv4 running out and the need to move to ipv6 for so many years/decades, but it keeps not happening. I’m wondering if anything will change in my lifetime.
IPv4 ran out a decade ago, the only reason why it continues to work at all is because of two things:
- Compatibility bridges for v6-only hosts to connect to v4 servers
- The IP address market encouraging old v4 allocation owners to sell off their space (at the expense of a bloated routing table)
In 2009, IANA and the RIRs created a process for buying and selling IP addresses. Which is something they never wanted to allow, but their hand was forced by the abysmal levels of v6 adoption back then. Two years later IANA would allocate the last /8s, and the RIRs that got those allocations would exhaust them in the years following[1]. The only virgin v4 address space remaining is reserved specifically for ISPs setting up v4 compatibility for native v6 networks.
You did not notice this because the v6 transition has already happened, and it was boring. In 2023, Google reports 40-45% v6 adoption[0]. This is largely due to LTE making v6 a mandatory feature. Had we kept mobile traffic on v4, networks would've adopted shedloads of CGNAT, and even then that hits a wall when you start running out of ephemeral ports to disguise addressing information inside of. This would have resulted in significantly worse behavior for smartphone users, especially in heavily populated countries like India (which have far higher v6 utilization).
[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...
[1] https://en.wikipedia.org/wiki/IPv4_address_exhaustion
- Compatibility bridges for v6-only hosts to connect to v4 servers
- The IP address market encouraging old v4 allocation owners to sell off their space (at the expense of a bloated routing table)
In 2009, IANA and the RIRs created a process for buying and selling IP addresses. Which is something they never wanted to allow, but their hand was forced by the abysmal levels of v6 adoption back then. Two years later IANA would allocate the last /8s, and the RIRs that got those allocations would exhaust them in the years following[1]. The only virgin v4 address space remaining is reserved specifically for ISPs setting up v4 compatibility for native v6 networks.
You did not notice this because the v6 transition has already happened, and it was boring. In 2023, Google reports 40-45% v6 adoption[0]. This is largely due to LTE making v6 a mandatory feature. Had we kept mobile traffic on v4, networks would've adopted shedloads of CGNAT, and even then that hits a wall when you start running out of ephemeral ports to disguise addressing information inside of. This would have resulted in significantly worse behavior for smartphone users, especially in heavily populated countries like India (which have far higher v6 utilization).
[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...
[1] https://en.wikipedia.org/wiki/IPv4_address_exhaustion
> but it keeps not happening
The article you're responding to is a dramatic demonstration that it has happened: Amazon's IPs would not be worth $4.5B if we hadn't run out. It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.
The article you're responding to is a dramatic demonstration that it has happened: Amazon's IPs would not be worth $4.5B if we hadn't run out. It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.
> It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.
There can only be ~4.3 billion IPv4 addresses, which means that mathematically IP addresses are severely limited - you can't assign even one single globally routable IPv4 address per human. That's why we have NAT and its evolution CGNAT in the first place.
There can only be ~4.3 billion IPv4 addresses, which means that mathematically IP addresses are severely limited - you can't assign even one single globally routable IPv4 address per human. That's why we have NAT and its evolution CGNAT in the first place.
That’s their point, if there were more addresses we wouldn’t need to
Back when the Internet was conceived, as a network of militaries, universities and large corporations, it was in no way foreseeable just how much resources humanity would need - and it was thought that the system would adapt.
However we got layers upon layers of closed-source middleboxes and everything ossified as a result.
However we got layers upon layers of closed-source middleboxes and everything ossified as a result.
But from the perspective of anyone that isn't a networking expert, there is no real problem, things just work and there are no real issues. Networking folks found ways to extend the runway and all other tech people see is the occasional article like this and then they forget about it again five minutes later. I don't even see the effects of the cost of an IP anywhere. I guess it's there, but I don't notice. No regular person even knows what ipv6 is.
ipv6 is _the_ mobile and india internet, mostly.
iphones are v6 only as are indian consumer connections.
iphones are v6 only as are indian consumer connections.
> iphones are v6 only
Are you sure about this? Do you have a link with details?
If I disconnect from WiFi and use the SIM card currently in my iPhone, and I go to one of the websites that tell me my public IPv4 and IPv6 address it shows that the mobile internet connection I have with this SIM card is IPv4 only.
iPhone 14 Pro
Are you sure about this? Do you have a link with details?
If I disconnect from WiFi and use the SIM card currently in my iPhone, and I go to one of the websites that tell me my public IPv4 and IPv6 address it shows that the mobile internet connection I have with this SIM card is IPv4 only.
iPhone 14 Pro
just checked again on an iphone se, 1st-gen, ios 15.x on t-mobile reseller in germany:
actually there is a v4 default route on the wwan-interface that appears to be a p2p link (192/32) probably to a cgnat.
besides 127/8, there are a only v6 routes, a lot of them.
actually there is a v4 default route on the wwan-interface that appears to be a p2p link (192/32) probably to a cgnat.
besides 127/8, there are a only v6 routes, a lot of them.
how do you check the routing table from the iphone? a jailbreak? some app?
Hurricane Electric Network Tools can do it.
Its an app.
Its an app.
kind of brings up the question if all apps can do this
Here’s the routing table that the HE.net Network Tools shows for my cellular connection shortly after I’ve turned off WiFi on my iPhone 14 Pro.
None of the entries in the cellular routing table is IPv6 with my current SIM card. So I am doubting more and more the claim that iPhone is somehow IPv6 only.
Seems more like some people have carriers that choose to provide them IPv6 only, and because of that they think that it has to do with the iPhone itself.
PDP_IPO (CELLULAR DATA)
default via 10.10.67.87 UGSC
10.10.67.87 via 10.10.67.87 UHr
10.10.67.87/32 via link#3 UCS
10.255.91.156 via 10.10.67.87 UGHWli
17.57.144.87 via 10.10.67.87 UGHWli
224.0.0/4 via link#3 UmCS
255.255.255.255/32 via link#3 UCS
None of the entries in the cellular routing table is IPv6 with my current SIM card. So I am doubting more and more the claim that iPhone is somehow IPv6 only.
Seems more like some people have carriers that choose to provide them IPv6 only, and because of that they think that it has to do with the iPhone itself.
PDP_IPO (CELLULAR DATA)
default via 10.10.67.87 UGSC
10.10.67.87 via 10.10.67.87 UHr
10.10.67.87/32 via link#3 UCS
10.255.91.156 via 10.10.67.87 UGHWli
17.57.144.87 via 10.10.67.87 UGHWli
224.0.0/4 via link#3 UmCS
255.255.255.255/32 via link#3 UCS
> So I am doubting more and more the claim that iPhone is somehow IPv6 only.
as well you should. the phone has to keep working.
my point was that smartphone ecosystem is ime very well established in the v6 internet and i doubt that any carrier assigns public v4 here.
as well you should. the phone has to keep working.
my point was that smartphone ecosystem is ime very well established in the v6 internet and i doubt that any carrier assigns public v4 here.
I have two carriers, one assigned v6 only, another is dual stack. My route file is much more complicated, but it might be related to both Wi-Fi calling and VoLTE.
That tool looked useful. Installed it and it immediately crashes when I tap "interface information". I guess my IP addresses are extremely top-secret.
There's no reason for the 'rest of us' to do anything. Prices will move enough users out to ipv6 so that the ipv4 market will always be in equilibrium. Due to particular reasons (specific design of ipv6, human population maxing out at about 10bil, main users getting their own ipv4 addresses already) ipv4 will never entirely go away - which is not something we should care about.
Just wait. The people who don't already support IPv6 can't really be influenced.
Make sure your ISP already configures IPv6 correctly and if not write them.
My ISP (Liberty Global) did configure IPv6 but then made your IPv4 to be a CGNAT ending in next state over.
Sigh
Sigh
NAT64 and DNS64 can help your v6-only hosts cope with the ubiquity of v4-only hosts.
Update link to actual article link: https://toonk.io/aws-ipv4-estate-now-worth-4-5-billion/index...
Extremely surprised that I could load that massive json list of ips on my phone instantly
I agree.
But in some sense it’s even more wonderful that your phone can (probably) render 1080p60 video without skipping a beat. Not to mention that it is transmitted over thin air, originating from someone (probably) thousands of miles away.
And even more wonderful is that no one thinks of it as anything special, at all.
But in some sense it’s even more wonderful that your phone can (probably) render 1080p60 video without skipping a beat. Not to mention that it is transmitted over thin air, originating from someone (probably) thousands of miles away.
And even more wonderful is that no one thinks of it as anything special, at all.
Out of interest, I opened link with this json file and scrolled till the end of it on a very cheap Android tablet from 2012 with Allwinner A10 (One 1GHz core) and 512mb of RAM, using lightweight Via browser without much trouble.
can I buy one ipv4 for myself somehow. not lease or rent, buy ?
Last I checked, the smallest blocks for sale are class C.
I also don't think there are many places willing to announce your ultra specific route because it's not great for routing tables.
I also don't think there are many places willing to announce your ultra specific route because it's not great for routing tables.
I think a colo would be happy to announce your /24, wouldn't they?
A /24 sure, but GP was asking about buying a single IP address.
No, the minimum allocation is a /24 (for v4) or a /32 (for v6)
Its a /48 for IPv6.
Thats what I have in my RIPE Account.
Thats what I have in my RIPE Account.
As I understand it, the current policy allocates /48 for special purposes. Normally allocations that small are supposed to come from an LIR, not directly from an RIR.
I was sponsored by a LIR for RIPE, but RIPE is the entity that gives out the /48 for me specifically. Its still PI space that I can announce with any ISP.
I could request a /32, but a /48 is definitely enough for me. Might request a second /48 at some point maybe.
I could request a /32, but a /48 is definitely enough for me. Might request a second /48 at some point maybe.
The smallest prefix that can be routed is a /24, so that's the minimum amount you can get.
What is the IP "ownership" model? is $35 to "own" the IP. What is the law around this (do companies contest who owns what IP)
IP blocks allocations are assets but they are granted by the RIR. [1] Your allocation is given to you in exchange for being a member of the RIR. You don't actually own the IPs, but you do have exclusive rights to them but the RIR can ultimately decide to revoke your rights to them for violating RIR policies.
RIRs do allow you to transfer your IP blocks to other organizations but you can only do so if the receiving organization proves to the RIR they have a good reason to hold those blocks of IPs. This valuation is based on what a typical IPv4 owner receives in exchange for that transfer of IPv4 addresses.
Just like any assets which you hold a lot of, if AWS dumped their IP addresses on the transfer market, the price of IPv4s would likely fall significantly so I doubt they could actually get that price for all their IPv4s.
[1] https://en.wikipedia.org/wiki/Regional_Internet_registry
RIRs do allow you to transfer your IP blocks to other organizations but you can only do so if the receiving organization proves to the RIR they have a good reason to hold those blocks of IPs. This valuation is based on what a typical IPv4 owner receives in exchange for that transfer of IPv4 addresses.
Just like any assets which you hold a lot of, if AWS dumped their IP addresses on the transfer market, the price of IPv4s would likely fall significantly so I doubt they could actually get that price for all their IPv4s.
[1] https://en.wikipedia.org/wiki/Regional_Internet_registry
The precedent for this came from Nortel's bankruptcy where they sold IPs to Microsoft. Some tried to argue that Nortel should have given up the addresses for free but the court ruled that IPs are property.
ELI5, why are IPv4 addresses so precious?
There is a finite amount of them - 2^32, some 4.3 billion - the limitation stems from using 32-bit values to express them. We cannot have more added, as the "capacity" of the 32-bit IP address value to provide different numbers has been exhausted by "assigning" these blocks of IP space - back in the old days of the Internet, large blocks of IP space were given to large organizations (such as Xerox mentioned in the article), now cloud hyperscalers are buying them back at a premium so their customers can use it to host things.
Because there are only 4.3B of them possible, and we've not done the best job of migrating to IPv6.
Said another way, AWS owns approximately 3% of all IPv4 addresses.
Said another way, AWS owns approximately 3% of all IPv4 addresses.
I understand that they are limited, but that doesn't explain why are they sought after?
Essentially, how are they better than IPv6 addresses?
Essentially, how are they better than IPv6 addresses?
Only approximately 45% of clients support IPv6. Clients that don't support IPv6 can't talk to IPv6 servers. Depending on your target market, that might be as high as 70% (India, France) or as low as 0.2% (several african countries). Today most of these devices will have some form of IPv4 connectivity, though it's often through NAT, which is slower and problematic for P2P like games.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Thank you for the short but clear explanation.
The main reason is they "just work" and they're now a scarce resource.
Having something that's addressable on the internet is trivial when you have a public IPv4 address.
Having something that's addressable on the internet is trivial when you have a public IPv4 address.
[deleted]
IPv4 address space was the actual bitcoin...
Is it possible that someone could start some kind of IPv4 ETF? Would be interesting to see - call it the Web 1.0 ETF.
RIRs oversee all IP ownership changes, and will generally not approve them unless they satisfy a documented technical need. So far, this has (mostly) prevented people from financializing IPv4.
Turning a critical peice of internet infrastructure into a financial toy for wall st would be a bit akin to taking all the physical barriers to access off of the nuclear football, authenticating it, and leaving it in a room full of bored children.
Don't do that.
Don't do that.
IPv4 is the new Bitcoin.
Can someone please ELI5?
The Internet is built on what is called version 4 of Internet Protocol, which when they designed it allotted 4Bn total IP addresses. Each device on the Internet would be able to have one IP and 4Bn would be more than enough for the whole of Planet Earth.
Fast forward a couple of decades and everyone needs 10 IPs each. You have your phone, your laptop, your work computer, your TV, your door lock, your door bell camera, your thermostat, etc. And every web site in the world traditionally needed its own IP. And so the world pretty much ran out of those 4Bn addresses.
The "Powers That Be" developed IPv6 which solves this, but not everything works properly yet when connecting with IPv6, so if you want to make sure your software/hardware is guaranteed to connect to everything then you need one of those precious IPv4 addresses.
Now, in the early days of the Internet there were so many addresses that they were handed out like Halloween candy. And many people had so many they didn't even use a fraction of them. So now you can make good money selling your old addresses as they are prime real estate.
Fast forward a couple of decades and everyone needs 10 IPs each. You have your phone, your laptop, your work computer, your TV, your door lock, your door bell camera, your thermostat, etc. And every web site in the world traditionally needed its own IP. And so the world pretty much ran out of those 4Bn addresses.
The "Powers That Be" developed IPv6 which solves this, but not everything works properly yet when connecting with IPv6, so if you want to make sure your software/hardware is guaranteed to connect to everything then you need one of those precious IPv4 addresses.
Now, in the early days of the Internet there were so many addresses that they were handed out like Halloween candy. And many people had so many they didn't even use a fraction of them. So now you can make good money selling your old addresses as they are prime real estate.
And the people who designed IPv6 designed a beautiful, perfect protocoll that was incompatible with the old IPv4 protocol. Which meant that a graceful, gradual shift to IPv6 was impossible. Cheap IoT devices are still being manufactured that support only the old protocol.
Oh boy do I have a great news for you!
https://en.wikipedia.org/wiki/Thread_(network_protocol)
Some IoT devices are now IPv6-required.
https://en.wikipedia.org/wiki/Thread_(network_protocol)
Some IoT devices are now IPv6-required.
> Fast forward a couple of decades and everyone needs 10 IPs each. You have your phone, your laptop, your work computer, your TV, your door lock, your door bell camera, your thermostat, etc.
Your phone perhaps, but the rest of these devices never need a public IP address.
Your phone perhaps, but the rest of these devices never need a public IP address.
The purity of IPv6 doesn't want NAT. Therefore, yes, all of those devices are supposed to have public addresses.
We can debate whether that's a good thing or a bad thing, but that is the way IPv6 is supposed to work.
We can debate whether that's a good thing or a bad thing, but that is the way IPv6 is supposed to work.
We should abandon the very idea of "public" and "private" addresses. An IP address is just an IP address, a globally-unique number that identifies a networked device. If you want a device to be inaccessible by other devices, throw in a firewall. NAT is just a firewall with packet-modifying capabilities anyways.
Your phone never needs (nor gets) a public IP either.
Pretty much every cell network gives the phone an IP on the subnet, and then uses NAT, or CG-NAT[1] to share the same public IPs for multiple mobile devices.
[1]: https://en.wikipedia.org/wiki/Carrier-grade_NAT
Pretty much every cell network gives the phone an IP on the subnet, and then uses NAT, or CG-NAT[1] to share the same public IPs for multiple mobile devices.
[1]: https://en.wikipedia.org/wiki/Carrier-grade_NAT
Anyone who wants to put a computer on the internet needs a phone number. There are now more computers than phone numbers, especially old ones without an area code or country code. As a result, those numbers are bought and sold, and amazon now owns 4.5 billion dollars worth of them.
Here’s your new cryptocurrency, all hail IPv4Coin!
IPv6 Excuse Bingo:
* https://ipv6bingo.com
* https://ipv6bingo.com
I don't run IPv6 on my home network. I try it about once a year, enabling it at the router (it's already enabled on my laptop).
And then random stuff just doesn't work. Various websites hang, various widgets just don't load, etc. Then I turn it off and everything gets better again.
I'be been too lazy to diagnose why exactly it doesn't work, I just figure it's easier to run with it off. At some point a website I really want to access will require IPv6.
Hopefully by then whatever is broken will be fixed.
And then random stuff just doesn't work. Various websites hang, various widgets just don't load, etc. Then I turn it off and everything gets better again.
I'be been too lazy to diagnose why exactly it doesn't work, I just figure it's easier to run with it off. At some point a website I really want to access will require IPv6.
Hopefully by then whatever is broken will be fixed.
> And then random stuff just doesn't work. Various websites hang, various widgets just don't load, etc. Then I turn it off and everything gets better again.
Before I switched ISPs a few weeks ago to one without IPv6, I was with an ISP with IPv6 (dual-stack) for about five years and had zero problems.
In fact it worked 'too well' initially: when I was still IPv4-only I had put a bunch of Facebook domains in my iMac's /etc/hosts file pointing to 127.0.0.1 so that all those little icons would stop loading. At some point I noticed they were back.
After some head scratching over a day or so I realized that Facebook was IPv6-enabled, and so the icons were loading because AAAA records were working. Adding ::1 for Facebook in hosts fixed things.
Before I switched ISPs a few weeks ago to one without IPv6, I was with an ISP with IPv6 (dual-stack) for about five years and had zero problems.
In fact it worked 'too well' initially: when I was still IPv4-only I had put a bunch of Facebook domains in my iMac's /etc/hosts file pointing to 127.0.0.1 so that all those little icons would stop loading. At some point I noticed they were back.
After some head scratching over a day or so I realized that Facebook was IPv6-enabled, and so the icons were loading because AAAA records were working. Adding ::1 for Facebook in hosts fixed things.
One of the security issues with dual stack. Your attack surface is twice the size, and human error means you are more vulnerable.
Still unsure of the benefit of dual stack, but there are numerous costs.
Still unsure of the benefit of dual stack, but there are numerous costs.
You have some misconfiguration on your local network. It's hard to tell from your description, but I'd guess maybe you don't have the firewall rules configured for IPv6 or something. Breakage is extremely rare on the live web. I can't remember the last time I found a website that was only breaking on IPv6.
The other common mistake is blocking ICMPv6 completely. This creates a really broken IPv6 stack!
edit: I've been running dual-stack with Windows, macOS, iOS & Linux for at least a decade now - I think it's closer to 20 years than 10! I've never seen it be like the parent post for my personal use, but I have seen it broken like that in places I've worked with incorrectly configured routers/firewalls.
edit 2: this isn't a good idea for v4 either, but it's less broken than v6!
edit: I've been running dual-stack with Windows, macOS, iOS & Linux for at least a decade now - I think it's closer to 20 years than 10! I've never seen it be like the parent post for my personal use, but I have seen it broken like that in places I've worked with incorrectly configured routers/firewalls.
edit 2: this isn't a good idea for v4 either, but it's less broken than v6!
> You have some misconfiguration on your local network
I’m sure I do. But that’s sort of the point. I only use standard commercial hardware with the default config.
If that doesn’t work out of the box, what chance does someone who doesn't have my decades of networking experience have in fixing it?
Granted I’m probably more sensitive than most because I know what network issues look like. Most people probably just think some things are slow sometimes.
My ultimate point though is that this is probably a barrier to adoption.
I’m sure I do. But that’s sort of the point. I only use standard commercial hardware with the default config.
If that doesn’t work out of the box, what chance does someone who doesn't have my decades of networking experience have in fixing it?
Granted I’m probably more sensitive than most because I know what network issues look like. Most people probably just think some things are slow sometimes.
My ultimate point though is that this is probably a barrier to adoption.
I think there's largely three groups that home users fall into here:
1. people who just use the router their ISP provides
2. people who go and buy off the shelf consumer routers/wifi - eg Netgear, Linksys, TP-Link
3. the kinds of people who run home labs and use small/medium business targeted routers/wifi like pfSense, VyOS, Unifi, Mikrotik, or even things like Juniper SRXes etc.
The first group will get a 'blessed' and hopefully well tested IPv6 configuration when their ISP rolls it out, and I'd expect minimal problems there. Certainly haven't noticed anything big in the UK with some of our biggest ISPs rolling out v6.
The third group will inevitably have teething troubles, but v6 works okay on those kinds of platforms once you know how to configure it, from my experience.
The second group is where a lot of the pain will sit, imo. I've found consumer routers have really bad IPv6 implementations (things like broken prefix delegation, broken firewalling that can't be changed, IPv6 negotiation not working over PPPoE, weird RA settings, etc). The firmware on these kinds of devices is usually not great, and things like hardware acceleration engines in router CPUs are also frequently missing acceleration paths for v6 for things they already accelerate for v4. It will get fixed eventually, but it's going to be a pain point for a lot of years to come.
1. people who just use the router their ISP provides
2. people who go and buy off the shelf consumer routers/wifi - eg Netgear, Linksys, TP-Link
3. the kinds of people who run home labs and use small/medium business targeted routers/wifi like pfSense, VyOS, Unifi, Mikrotik, or even things like Juniper SRXes etc.
The first group will get a 'blessed' and hopefully well tested IPv6 configuration when their ISP rolls it out, and I'd expect minimal problems there. Certainly haven't noticed anything big in the UK with some of our biggest ISPs rolling out v6.
The third group will inevitably have teething troubles, but v6 works okay on those kinds of platforms once you know how to configure it, from my experience.
The second group is where a lot of the pain will sit, imo. I've found consumer routers have really bad IPv6 implementations (things like broken prefix delegation, broken firewalling that can't be changed, IPv6 negotiation not working over PPPoE, weird RA settings, etc). The firmware on these kinds of devices is usually not great, and things like hardware acceleration engines in router CPUs are also frequently missing acceleration paths for v6 for things they already accelerate for v4. It will get fixed eventually, but it's going to be a pain point for a lot of years to come.
I agree with you, this is a great assessment. And of course I'm in group two. I'm sure it's the router's fault, but other than IPv6 it works great, so there isn't really much reason to change it or dig into it. I'll just wait until I actually need v6 and then worry about it.
And, each group is probably an order of magnitude smaller than the one before it - nearly everyone just uses their ISP's router.
A small number of people use routers you can buy from Amazon, or in a store.
A really tiny number of people use more professional equipment at home.
The problem is, most IT professionals fall into one of the smaller two groups, so they get more friction than others, and that leads to them having more reluctance to roll out v6 at work, etc.
A small number of people use routers you can buy from Amazon, or in a store.
A really tiny number of people use more professional equipment at home.
The problem is, most IT professionals fall into one of the smaller two groups, so they get more friction than others, and that leads to them having more reluctance to roll out v6 at work, etc.
You have decades of networking experience but you are unable to get ipv6 to work, something that over 40% of internet users are using daily.
[1] https://www.google.com/intl/en/ipv6/statistics.html
[1] https://www.google.com/intl/en/ipv6/statistics.html
I can get it to work just fine. It just doesn't work as well as IPv4 and I can't be bothered to figure out why.
I'm in that 40%. I use IPv6 on my phone whenever it's not in my house.
I'm in that 40%. I use IPv6 on my phone whenever it's not in my house.
[deleted]
Debian would just not run due to apt repositories being borked if ipv6 was turned on.
My network is dual stack and all my VMs are Debian. No issues here.
anything more concrete?
i was struck by an issue in this area a few years ago and i think it was fixed by tuning gai.conf to prefer v4 because there were some repo servers that had broken v6
i was struck by an issue in this area a few years ago and i think it was fixed by tuning gai.conf to prefer v4 because there were some repo servers that had broken v6
Which exact repo was that?
I seem to think that the primary UK mirror (http://ftp.uk.debian.org/) was problematic for v6 for a while? But these days the https://deb.debian.org/ mirror is really heavily pushed, and that one seems to work just fine.
edit: but this was quite a few years ago, from grepping my IRC logs, somewhere around 2016!
edit: but this was quite a few years ago, from grepping my IRC logs, somewhere around 2016!
there are thousands of debian mirrors, not that far fetched that at least one of them has broken v6
> At some point a website I really want to access will require IPv6.
kek - i too am waiting
kek - i too am waiting
I thought this one is interesting too https://awsipv6.neveragain.de/
These are some very compelling bingo items - I’m not sure if sharing this card is having the intended effect (unless you wanted me to continue to think that IPv6 isn’t ready for real use?)
>IPv6 isn't ready for real use
Tell that to 45% of the Internet.
Also, half of the bingo items there are intentionally humorous, and if you are taking those items literally (I wouldn't be able to tell, you never listed them out) - congratulations, you are part of the bingo :)
Tell that to 45% of the Internet.
Also, half of the bingo items there are intentionally humorous, and if you are taking those items literally (I wouldn't be able to tell, you never listed them out) - congratulations, you are part of the bingo :)
My work's VPN is horrifically misconfigured and breaks if I have IPv6 enabled, is that a good enough excuse?
Which divided by approximately 3.7 billion routeable addresses works out to about $1/address.
3.7B would be all routable IPv4 addresses. As the article points out, AWS only owns 127M routable addresses.
Indeed.
I can promise you no one is paying $35 per IPv4 address.
i disagree. skuhn posted a link to some historical data https://auctions.ipv4.global/prior-sales
Based on data from the IPv4 brokerage ipv4.global, the cost of IPv4 addresses has seen a notable increase. In 2014, the price ranged from $6 to $24 per IP, depending on the size of the subnet. By 2021, this range had jumped to between $23 and $60 per IP. The fluctuation between the lowest and highest sales prices for each IPv4 address remained relatively stable until 2021, when we began to see more significant spikes.
The peak prices for IPv4 addresses in 2021 were observed in September and October. During these months, IP addresses allocated by RIPE NCC and ARIN fetched as much as $60 each. Specifically, a /24 block from RIPE NCC sold for $15,360, while ARIN's /22 and /23 blocks went for $61,440 and $30,720, respectively.
Fast forward to October 2022, and the highest sale of the year was recorded: IP addresses allocated by ARIN sold for $60.70 each, or $15,540 for a complete /24 block. Despite these peaks, the IPv4 market appears to have reached a more stable pricing structure, especially when compared to the more volatile price shifts seen in 2021.
Based on data from the IPv4 brokerage ipv4.global, the cost of IPv4 addresses has seen a notable increase. In 2014, the price ranged from $6 to $24 per IP, depending on the size of the subnet. By 2021, this range had jumped to between $23 and $60 per IP. The fluctuation between the lowest and highest sales prices for each IPv4 address remained relatively stable until 2021, when we began to see more significant spikes.
The peak prices for IPv4 addresses in 2021 were observed in September and October. During these months, IP addresses allocated by RIPE NCC and ARIN fetched as much as $60 each. Specifically, a /24 block from RIPE NCC sold for $15,360, while ARIN's /22 and /23 blocks went for $61,440 and $30,720, respectively.
Fast forward to October 2022, and the highest sale of the year was recorded: IP addresses allocated by ARIN sold for $60.70 each, or $15,540 for a complete /24 block. Despite these peaks, the IPv4 market appears to have reached a more stable pricing structure, especially when compared to the more volatile price shifts seen in 2021.
https://auctions.ipv4.global/prior-sales
$30-35 is the low end per IPv4 address over the last year.
$30-35 is the low end per IPv4 address over the last year.
People who need them on short notice often pay more. The rent AWS collects on their IPv4s also pays that off in a year, I think.
How much does Amazon charge? I pay about 50 Euro cents a month to Hetzner for mine.
I've tried running web servers as pure IPv6 plays, which I would happily, happily prefer. It is just not possible. Even things I'm convinced will work, like cellphones, which are mostly IPv6 these days, won't connect.
I've tried running web servers as pure IPv6 plays, which I would happily, happily prefer. It is just not possible. Even things I'm convinced will work, like cellphones, which are mostly IPv6 these days, won't connect.
AWS charges $0.005 per IP per hour. Multiplied by 8760 hours, you get about $44/year at 100% utilization.
Go on...what are people paying then? More or less?
If you are willing to wait, you pay nothing. However, let's keep in mind that this evaluation is based on the private transfer market place for IPv4s not based on actual RIR costs.
You must be an RIR member to hold IPs and there are membership dues that you must pay each year to maintain your allocation. Once you are a member of an RIR you just have to make a request and at least with ARIN that request and fulfillment is free.
You must be an RIR member to hold IPs and there are membership dues that you must pay each year to maintain your allocation. Once you are a member of an RIR you just have to make a request and at least with ARIN that request and fulfillment is free.
ARIN’s free pool of IPv4 address space was depleted on 24 September 2015. As a result, we no longer can fulfill requests for IPv4 addresses unless you meet certain policy requirements that reserved blocks of IPv4 addresses for special cases. https://www.arin.net/resources/guide/ipv4/
ie. you have virtually no other option than to buy on the private market
ARIN is the first to deplete.
I think other RIR still IPv4 left.
But the wait is long and everyone is rationing addresses so any free allocation is unlikely to be very large.
What's the thought on Amazon stock price? Is their dominance of the web built in to their price or does it have room for significant growth in the next 5-10 years?
"Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...