Hacker News new | past | comments | ask | show | jobs | submit login

I've been thinking, we really just need lots and lots and lots of IP addresses, far more than we realise right now. ipv8? Should probably be ipv32 or some such.

An example ; when we start throwing smart nano on the grass, to see how each blade of grass is doing on your lawn. Well, each nano is going to need an IP address, and so will all in the neighbourhood. And that's just the grass.

What about when some scientist wants to track sand dispersal patterns, on a beach, after a hurricane? And wants to have each grain of sand tagged with its own nano hitchhiker? Just think of the IP addresses we'll need then!

And even medicine. What if we want to interally tag each cell in our bodies with nano? What if we want to bioengineer our body, so that each cell has its own IP address? And can report health/condition?

No, we need more, more more IP addresses! So many more.




> What if we want to interally tag each cell in our bodies with nano?

There will need to be multiple addresses for all the nano-services running inside each of those nanobots. Solution: install a k8s cluster with each nano...


Yes or install a main router/access point for each human that sub-adresses all nanobots. Or do you want them exposed to the broader internet?



This part really drives it home:

"[...] assign an IPV6 address to EVERY ATOM ON THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths."


Well, IPv6 has 128 bits, so 3,4 x 10^38 adresses. Surface area of the Earth: 5,1 x 10^14 m2. Maybe adressing grass blades could be possible with IPv6.


It's something like a /48 for each second m^2 of Earth's land surface. Single addresses are not a useful metric, as IPv6 works a lot more with prefixes (groups of addresses, to simplify management and allow things like auto-configuration). The smallest prefix that you would assign to a VLAN with auto-configuration is /64. So /48 (or 65 536 subnets) in IPv6 would be the equivalent of /16 (like 192.168.X.X but global unicast) in IPv4. That is what normal businesses usually get. Home customers should get a /56 of IPv6, that still leaves space for 256 subnets with basically unlimited hosts in them. Not too bad I think.


I never got why they had to make it that large. I doubt we'll ever want to have that many devices with their unique ip. So why not have a simpler system that makes switching easier? Even one octlet more in ipv4 would've sufficed for a very long time, two would've probably been enough forever.


Two reasons I think.

The first is, they were working on this before the Internet was widely used. Back in dialup days, pre-2000, the draft presented in 1998, working on it in 1995 and before surely.

Compared to today's scope and size, this was nascent/early style change, in something which was constantly changing.

They didn't see any contention likely at the time. Why not have all the universities, government departments, and research bodies switch? This was an entirely different landscape compared to today.

So in their eyes, why not make change? It wasn't a big deal, hell back in the early 90s, people were using token ring adapters/networking still in many offices!!

The second thing is, NAT wasn't a thing back then. The computational power was a limiter for large scale usage.

An RFC for NAT came out in 98 I think, and Linux had ipmasq, but that was brand new in the early 90s.

Basically, ipv6 was crafted before anyone had any idea we'd be where we are today.

In fact, the worry about address space exhaustion in the early 90s was due to a lack of NAT, or even the idea that it could be deployed everywhere at scale.

Where would all the compute power for NAT at scale come from?!

So basically, it was crafted with a different viewpoint.


I wonder how much electricity NAT is consuming globally?

That would be a good BS level graduate thesis paper for someone interested.


I think the sand and the grass can use NAT :)


Society will collapse before we ever have a need for more IPs than what’s in v6.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: