In fact I can only see IPv6 making things worse in that regard because tons more address space means that more AS assignments would be easy to do.

In reality it works the other way around.

With IPv4 there is a shortage of addresses, so ISPs haven't been getting extremely large blocks. They have been getting blocks just large enough to get by for another year, then they could get another block. Renumbering from multiple smaller blocks into a larger block isn't an option for IPv4, because there isn't enough available address space to shift things around.

With IPv6 an ISP can get a single block, which is large enough for years to come. And the address space around it is being kept free by the RIR, such that should the ISP need more space, their existing block can simply be made larger.

This means an ISP that have 20 different IPv4 blocks announced individually could support the same number of customers with a single IPv6 block. On average each AS announcing IPv4 space announce five times as many IPv4 prefixes as the number of IPv6 prefixes announced by those prefixes announcing IPv6 space.

This is all due to the HD-ratio of IPv4 having been pushed way above the reasonable threshold. IPv6 is designed to work with an HD-ratio of only 80-90%.

Your "solution" is a bunch of horrible hacks that don't even work with DNSSEC.

That didn't stop DNS64+NAT64 deployments. DNSSEC is not widely deployed, which is why IPv6 transition mechanisms that are incompatible with DNSSEC would still be usable. DNSSEC also hasn't solved the amplification attacks problem yet. I'd love to see DNSSEC deployed, but I am personally not going to put much effort into DNSSEC until the day I no longer have to worry about IPv4.

Essentially you have "NAT" functioning at the DHCP+router+DNS level, all conspiring to mangle packets in concert.

Turns out it still works better than carrier grade NAT.

I have a fully working system similar to what you describe.

Theoritically, any block of Ipv4 addresses outside of the local subnet could be used

Squatting on global unicast space would not be a good idea at this time. You still want to be able to communicate with existing IPv4 backbone. Once the IPv4 backbone is ready to be deprecated, such a system could start reusing global unicast space.

Until then, RFC 1918 addresses do work just fine for the purpose. RFC 6598 addresses might be better, I haven't tested yet. Addresses from the reserved class E address space won't work well for this purpose. I tested and found that it works with some systems, but other systems refuse to communicate with peers on class E addresses.

a pool of 131072 ipv4 addresses, plenty for most use cases.

Depends on how large a network you deploy it to. For a single broadband connection, that size is plenty. But I don't think it would be sufficient, if you want to cover an entire ISP. If you can find me a network that want to deploy it, I'll tell you how far that pool size scales.

I doubt most people will have that many TCP connections at once.

In the end, the number of TCP connections won't even matter.

Since 127 is not used for local networks, it is the best choice however as the first choice.

127.0.0.0/8 has special meaning in practically every IPv4 stack. Trying to redefine that won't work well.

Nice to see somebody knowing what they are talking about. I am wondering if those allocating only a /60 to each customer does so due to using 6rd. If 6rd is being deployed on top of fragmented IPv4 address space, it becomes impractical to give each customer more than a /60.

I assume we agree, that taking the /60 you can get is better than staying on IPv4-only while you wait for a provider to offer a /56 or /48.

While in practice most admins configure /64s as subnets, there's nothing preventing netblocks that are smaller than /64.

But those are never advertised through BGP between AS. For backbone connections between AS 48 bits is sufficient. Within your own AS, you can use a hierarchical structure, which due to its hierarchical structure can be routed more efficiently.

To summarize - for the foreseeable future I guess 200k entries matching on the first 64 bits will be plenty for backbone routers. And 10k entries matching on all 128 bits will be plenty for edge routers.

There's no good reason to think there'll be a significant improvement in HD with IPv6, or significantly fewer prefixes advertised.

You'd need more than 10^12 internet users to push the IPv6 HD ratio up to the same ridiculous level that we have on IPv4 (for those bits that matter to backbone routing). Dagger2 is right, the HD ratio does have a measurable impact on number of advertised prefixes. The average number of adverstised prefixes per AS is five times higher on IPv4 than on IPv6.

This isn't really to do with BGP or IPv4 as such, it's an inherent problem in the way "The Internet" regards addresses.

It is a problem made five times worse by the extreme high HD-ratios needed to keep IPv4 alive. If we switch to IPv6, we can go on much longer before this becomes a problem again.

It may become a problem again after IPv4 has been abandoned as the network keeps growing. Something scaling better than BGP would be nice. I predict a more scalable solution is going to need more addresses - no problem for IPv6 but would make such a scalable solution unusable with IPv4.

Imagine if your business suddenly lost internet connectivity because your IP blocks have been reclaimed.

Who is going to configure their backbone routers to reject announcements from parties who got their addresses reclaimed for such reason? I don't see an incentive to reject those announcements, hence the reclaiming won't have any immediate effect.

This has little to do with IPv6. In fact there is only 256k available by default if you switch.

So what if you can only have half as many entries on IPv6? Due to IPv6 being designed for an HD-ratio in the 80-90% range rather than the 95%+ needed with IPv4, there is much less address space fragmentation. The result is that on average each AS only has one fifth the number of IPv6 routes compared to IPv4. So those 256k IPv6 routes are going to last longer, even if the entire world switched to IPv6 next month.

Seems like to fail all at once now is a sign of something intentionally wrong.

The only thing intentionally done wrong, that I am aware of, is ISPs not deploying IPv6 for a decade.

Every bit counts.

Not on backbone routes. Backbone routes only need 48 bits. And if you use the recommended link prefix length, you don't need longer than 64 bits anywhere. 64 bit networks ought to be enough for anybody.

Even if you decide to make your link prefixes longer than 64 bits, you don't need a CAM with thousands of entries for that. Most routers don't have thousands of ports.

Can the Earth be considered to be in the same league as Jupiter/Saturn

They are not considered to be in the same league. The classes are: Gas giants, terrestrial planets, dwarf planets.

Which is odd, considering iTunes, Windows Media Player and even Xbox 360 and PS3 will rip CDs.

It does make a difference whether the primary purpose of the device is to rip CDs. But I believe the real reason they didn't go after those devices is, that there may not be enough money to go after.

The devices you mention probably cost less than 2500$ per unit. A car could cost significantly more than 2500$, so it would be a lot easier to squeeze 2500$ per unit out of a car manufacturer.

That strategy could backfire if in the end the question about the primary purpose gets applied to the entire car and not just the CD player. I don't think they'll manage to convince the court that the primary purpose of the car is to rip CDs.

Using blockchain technology for decentralized consensus.

If you are thinking about using bitcoin style proof of work, then I'd say that is a poor choice. It is an extreme waste of processing power, and it is not even needed for DNS. The purpose of the proof of work is to prevent double spending. But if you tried to perform a double-spending like action on a DNS system build on similar principles, the only damage you'd cause would be to your own domain.

But by all means, let's get data and hosting decoupled. DNSSEC provides the ability to validate records, wherever you got them from. But it still has the centralized authority. I'd rather see that once a zone hand over authority over a subdomain to a different public key, then a signature with that key has to be used to hand authority back or transfer it to a new key.

it it possible or even practical to identify a bitcoin as having been a "direct descendant" of a coin involved in a given transaction and/or as a coin that has been "co-mingled" with such a coin?

Definitely. That is easy to do. However since each transaction can have multiple inputs and outputs, the set of descendants is likely to grow over time, until eventually most bitcoins are descendants of that transaction.

it may make it practical to for major players and for that matter anyone who uses BC to "locally blacklist" seized bitcoins.

If there isn't any consensus in the "community", then such a blacklist is unlikely to have any effect.

If some miners decide to blacklist transactions involving certain coins, then other miners are just going to pick them up. If only a minority of miners are in on the blacklisting, then this is going to cause a fork in the blockchain. Other miners have to decide, which fork they are going to bet their resources on. If there isn't consensus on what to blacklist, there could be so many forks blacklisting different subsets, that each fork is going to become irrelevant leaving only the chain with no blacklisting as viable.

Even if you could manage to get a majority of miners to agree on exactly what should be blacklisted, it is of questionable value to the miners to attempt blacklisting. It could be seen as introducing a dangerous precedence for introducing blacklists. This would introduce a new and even more unpredictable danger to anybody owning bitcoins.

Traders could decide to blacklist certain bitcoins. This would mean you would refuse to accept blacklisted coins. But if you are selling goods for bitcoins, then you'd have to announce in advance, which coins you consider blacklisted, otherwise you'd have disputes where the buyer of goods says they have paid, but seller of goods says the received bitcoins are no-good. And as receiver of bitcoins you'd also have to decide how diluted the blacklisted bitcoins would have to be, before you'd accept them. And in all, there'd have to be consensus about both the set of blacklisted bitcoins and the dilution threshold. Otherwise nobody will know, if the bitcoins they are accepting are good or not, and without such knowledge blacklisting wouldn't have the intended effect, instead you'd just be rejecting arbitrary payments, you might as well flip a coin and say no-thanks to a certain payment.

I think the only consensus that has a real chance of being reached is that bitcoins are not blacklisted.