IPv6 is a 'tragedy of the commons' issue just like recycling: you get no benefits to you individually from addressing the issue.
However the day the issue is solved, and ee can forget IPv4, a myriad issues dissapear - routing, port forwarding, P2P software for torrents and calls, multiplayer games, etc.
As often when people reference the metaphor of the tragedy of the commons, which had no historical basis in reality (quite the opposite), there's more going on here.
IPv4 addresses are a significant competitive moat for incumbent businesses. Existing companies have no interest in making IP addresses a non-scarce resource that aids competitors or alternatives (on-prem hosting, p2p, local ISPs, etc).
The only reason things have begun changing recently is government mandates and that the moat has gotten so big that they've started falling into it themselves.
Tangent, but as someone who often finds the tragedy of the commons as the simplest explanation to many things, I'm interested in hearing your take on it
There's a lot of more qualified people who have written better criticisms of it than I can, but it generally boils down to a few things:
1. Lack of basis in reality. While of course there are occasional cases of communities mismanaging resources, this was and is far from univeral or usual. In fact the english public land that the thought expermiment gets it's name from and claims can not work had succesfully been in common ownership for to my knowledge all of recorded history until it's relatively recent enclosure (privatization).
2. It supposes the commoners would desire infinite short term growth above and beyond what they needed, could personally tend to or the land could sustain. This is both ahistorical and circular logic. In reality commoners had long known the amount of cattle the commons could sustain and allocated limits among themselves.
3. Where examples of over-grazing do exist, it was as a result of deliberate action by wealthy people to drive commoners off of the land for enclosure. This is not unlike the patterns we do commonly see in the real world today, where resource exhaustion generally takes place when there there are big power differences.
4. Far more than as a prediction of reality, it has been successful as a justification for various unsightly things, from land theft and colonialism past and present, to eugenics and global poverty. It is not a neutral description of human nature and historical tendencies, but a distortion of them that aids the wealthy and poweful.
If you are looking for a better alternative I suggest you look at the power relationships between the people who are using the commons instead, it's usually much more enlightening.
Well, you are gonna have to replace port forwarding with firewall rules instead. At least for me, I really don't excited about my parents or in-laws internal networks being wide open to the internet. Thus their entire subnet would need to sit behind a "default deny" firewall. And if they need to expose some service to the internet, they'd need to punch a hole in the firewall--which is exactly the same dance you'd have to play with port forwarding.
The only thing IPv6 brings to the table for consumers is each device gets a globally routable address. But that doesn't mean each device can or should be be reachable from outside the router. One way or another client software will not get away from having to open ports on the router.
The difference is that with a firewall, you open the port and that's that. With port forwarding, you get whatever port happens to be available. If done manually, you have to tell the other sode which port to use. If done automatically (like upnp), you need to do that every time your port changes.
There is no difference of opening a port in a firewall or a NAT (well, as long as there is a single machine that wants to listen on that port, at least).
And some kind of UPnP will still be required even if your internal network were using ISP-assigned IPv6 addresses for protocols that want to open multiple connections, like VoIP conferencing, bit torrent etc.
Of course, if you have an internal network where you actually communicate between your various machines, you won't want to use ISP-assigned publicly routable IPs, since those can change at any time, so you'll also need some kind of network address translation at the edge.
> well, as long as there is a single machine that wants to listen on that port, at least
Well yes, most networks have more than one machine and multiple users might want to run the same service.
> you'll also need some kind of network address translation at the edge.
Not at all, each machine gets two addresses - one routable from the ISP and one non-routable from the router. Internal services simply use the non-routable ones.
> And if they need to expose some service to the internet, they'd need to punch a hole in the firewall--which is exactly the same dance you'd have to play with port forwarding.
The difference being, with IPv4 only one machine in the house can have a port open. You don't just open a port, you choose _which_ single machine gets the port. Sometimes you can't open a port on a machine because the port's already taken.
With IPv6 any/every machine can have the same port open at the same time.
The setup you describe, a default deny firewall, is in fact how consumer routers operate. It's not something you need to configure yourself - router manufacturers do this by default, as recommended by RFC 6092. The idea that IPv6 home networks are "wide open to the internet" is a myth.
Real estate on the blockchain is my favourite bad blockchain idea because if someone loses access to their wallet they presumably lose the ability to ever sell their house.
Nah, it just becomes one of those impediments to sale that you wave aside during purchase and earns lawyers a few bucks.
There are a few of these in England, Chancel Repair Liability is the most famous. In theory you could be forced to pay for repairs to a nearby church you never visit and have no interest in, on account of land you own was historically liable for such repairs and this was never cancelled. A real person, this century, had to pay about £350 000 as a result, so that's not inconsequential (although the circumstances were pretty unusual). But that's scary enough that a real estate lawyer might argue they're not sure the property you want to buy is unaffected, you should take out Insurance against the liability, conveniently sold by another lawyer.
The government tried to "fix" this, but the problem with lawyers is, obviously no fix will be good enough to prevent lawyers saying what if the fix didn't work, so chances are you get persuaded to buy insurance even though the liability probably no longer exists because hey, if I'm wrong I'm not going to pay £350 000 so...
Fifty years from now, if the fact there's "an NFT on the blockchain" for a property you want to buy is even something anybody knows about, your lawyer will know, and they'll tell you that another lawyer offers $1000 insurance, buy that and if "the blockchain" ever tries to sue you and take the property back they'll have your back...
You just gotta etch the block into the foundation. Then it's physically part of the house. Maybe make a radioactive label and bury it on the property. That way people now the property they're standing is on actual property.
The startups in that article don't seem to be selling entire properties on the blockchain though - it looks like they're doing things like buying a property and then selling fractional interest in that property to different investors as tokens.
I'll believe that multi-sig wallets solve this when I hear frequent stories about regular human beings (not highly sophisticated tech insiders) who both understand them and use them successfully.
Or, do what enterprises do with sensitive documents: Store it with a custodian (or a hardware wallet).
Mutli-sig wallets are but one non-custodial solution.
Not long ago, Signal demonstrated a way to recover passphrases in a way that server compromise doesn't really reveal anything at all about the passphrase itself: https://signal.org/blog/secure-value-recovery/ The OPAQUE standard also has similar properties to Signal's design but much more cheaper to implement: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque... I point these out because Novi (Facebook's Diem wallet) implements the latter. These never require keys to ever leave a client device (which inturn could be a hardware wallet).
Useable security will take time. It was a long road from GnuPG to Keybase/Signal. Given the amount of cryptographers and engs building for "web3", I'm sure something useable will crop up. May be it is Moxie himself who comes up with it, who knows? ;)
It isn't as much about blockchain, than what NFTs enable. Properties can be sold digitally, like any other goods are on e-commerce websites, for example. Of course, NFTs aren't strictly needed, but could be used as a cryptographically secure (for some definition of secure [0]), publicly verifiable, record of ownership.
IPv4 addresses have utility. You still need one in order to participate in the largest communication network in the history of the earth. And theirs a limited number of them. Demand + Scarcity = non-zero price.
What utility do NFTs provide other than entertainment/status?
If the address space wasn't assigned to you via a RIR, it won't take long for someone to notice though and get your announcement by enough relevant large tier 1 & tier 2 ISPs that your announcement won't reach most of the Internet.
At that point you can of course use the addresses locally, but you can't reach the rest of the internet.
This type of squatting was somewhat easier in the past when less of the IPv4 space was actually in use and when less strict filtering (or RPKI) was in place.
Still happens, but it's getting harder and harder.
So lets say Centurylink decide to start advertising blocks they don't own, people like Cogent and Tata drop their links, people with multiple ISPs drop their links (shifting traffic to other tier 1 ISPs), and those with centurylink only change their ISP because they can no longer get to facebook.
That would work if most people had multiple ISPs, but most don't actually. Thus, you have some bargaining power, especially if you have some network advantage or feature nobody else has.
If you are leaking routes you shouldn’t then a decent ISP will disconnect your crappy network.
It happens a lot, usually because of mistakes, it’s typically fixed quickly.
Feel free to null route or redirect any IP you want in your network. Just don’t be surprised when other networks cut you off if you advertise those routes out of your network, and don’t be surprised when your customers are unhappy because you aren’t transporting the packet to the target IP as is your job.
If you really believe what you’re saying, which I find hard to believe myself, I recommend you try doing what you’re saying and report back the results.
They're a scarce commodity, and unlike NFTs, have a real use-case.
Until everyone moves to IPv6, if you want people to be able to reach your service, you need an IPv4 address. If you're an ISP or cloud provider, you need those so your customers can still communicate with v4-only peers.
ipv4 addresses are unique in the default free zone.
they cost money because without having a prefix that is unique, you cannot route across the internet.
IPv6 has a political issue. Support for IPv4 addresses (::0.0.0.0) was removed, because IPv6 users were able to connect to IPv4 hosts directly, bypassing IPv4 NAT's and firewalls.
> Support for IPv4 addresses (::0.0.0.0) was removed, because IPv6 users were able to connect to IPv4 hosts directly, bypassing IPv4 NAT's and firewalls.
How's that work? It can't be sending actual v4 traffic or it'd work like normal v4.
IPv6 is large enough to represent the whole IPv4 range. Multiple times. Initially (at the very beginning) it was possible to connect to IPv4 address using IPv6 socket. They were called «IPv4-Compatible IPv6 Address»[0]. For example, I can ping both ipv4 and ipv6 addresses using ping:
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.044 ms
However, this feature allowed to bypass NAT and connect to IPv4 hosts directly via IPv6, so it deprecated. (I skipped names to avoid scapegoating).
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.043 ms
$ ping6 127.0.0.1
ping6: 127.0.0.1: Address family for hostname not supported
It's not a technical issue, see above: it's possible to serve both protocols at the same time. It worked for a brief period. It's purely political decision: backward support for IPv4 in IPv6 was disabled because some people are thinking that such behavior is dangerous.
That's... really not how any of it works, and the ping examples are a red herring.
IPv4-compatible IPv6 addresses basically allows applications to connect to IPv4 hosts using just a single IPv6-compatible network stack. The operating system kernel handles the translation to and from IPv4 native. There's no way it can "bypass NAT" -- that doesn't even make sense, NAT causes the hosts behind a network to all have the same external network, the exact same incoming rules would apply as they always have.
As for ping: back in the 1990s and 2000s, ping only understood IPv4 addresses and an independent command "ping6" was made to work on IPv6. In the mean time, regular ping understand both protocols just fine and you don't need a separate one. Modern Linux distros don't even have a "ping6" anymore.
Ping is just example to illustrate that the problem is not technical in a way which makes it easy to understand. I'm talking about this issue for more than decade (at national level), so I nailed some patterns.
Yes, IPv4 packets and address range are too small to support IPv6, but IPv6 can encapsulate them with room to spare, so IPv6 network can address and handle IPv4 networks and hosts directly. However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network.
For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). Theoretically, when IPv6 will support both IPv6 and IPv4, I can expose my internal IPv4 network via IPv6, which may create security risk, same as for IPv6 native network without NAT.
This is the key problem: people don't want to expose internal networks to the public, so the feature was cut with hope that everyone will switch to IPv6 and this will no longer be a problem.
In 2004, I was lead of OPS team, so I spent some time trying to invent a way to switch our internal network to IPv6, when it will hit mainstream, and found that seamless transition is not possible at all: IPv6 requires switch, because backward compatibility is disabled, just because a corporation asked for that.
You're still confusing unrelated topics in the field.
> However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network.
If they share an IPv6 network, they can communicate over IPv6. If they are truly disconnected from each other with IPv4, they cannot in any way communicate over IPv4, this includes using, for example, "::ffff:192.168.1.1" as an address.
> For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo).
This has nothing to do with IPv4 encapsulating in an IPv6 stack. Instead, you've configured your host to have a public IPv6 address by way of using proxy servers to provide bidirectional communication. If you don't want this, stop using miredo.
> people don't want to expose internal networks to the public
Well, stop doing it. Stop running miredo if you don't want that behavior. Install firewalls and policies to block incoming traffic.
IPv6 doesn't magically transform your NAT'd IPv4 network into a public free-for-all space. You really have to work at opening up that possibility yourself (such as by installing/using miredo). IPv6 cannot in any way bypass a NAT and reach IPv4 hosts directly behind them. Encapsulated IPv4 packets in IPv6 are translated at some point along the chain (typically the computer running the application using an ::ffff:0.0.0.0/96 address) into the native IPv4 networking world where the packets are handled as if the application used an IPv4 address directly. The encapsulated addresses are primarily a convenience factor, nothing else, and no security implications.
(I sort of think you are also thinking of 6to4 and/or NAT64 in this discussion, which can punch a hole through your NAT in the way you are describing. If you don't want this, don't do this!)
Backwards compatibility isn't "disabled" in v6. There are plenty of backwards compatibility methods available.
You can do a seamless transition by deploying v6 and then undeploying v4 once you no longer need it. You can speed the second part up by using NAT64+DNS64.
It was using IPv6 in IP, just like 6to4, protocol 41.
I haven't heard it called a political issue before though. It just had problems, like being blocked in firewalls and security problems where the encapsulated packet wasn't checked properly, etc.
However the day the issue is solved, and ee can forget IPv4, a myriad issues dissapear - routing, port forwarding, P2P software for torrents and calls, multiplayer games, etc.