Hacker News Reader

Comment by efitz | Hacker News Reader

They’re just kicking the can down the road. What will people do on December 4, 292277026596, at 15:30:07 UTC?

Celebrate 100 years since complete ipv6 adoption.

I think you are being too optimistic. Interplanetary Grade NAT works just fine and doesn’t have the complexity of using colons instead of periods in its addresses.

The year is 292277026596. The IP TTL field of max 255 has been ignored for ages and would no longer be sufficient to ping even localhost. This has resulted in ghost packets stuck in circular routing loops, whose original source and destination have long been forgotten. It's estimated these ghost packets consume 25-30% of the energy from the Dyson sphere.

That’s only 25-30% of the energy environmental disaster in sector 137 resulting from the Bitcoin cluster inevitably forming a black hole from the plank scale space-filling compute problem.

Not since the world opted for statistical TTL decrement : start at 255 and decrement by one if Rand(1024) == 0. Voilà, no more zombie packets, TCP retransmit takes care of the rest.

Sounds like a great sci-fi plot - hunting for treasure/information by scanning ancient forgotten packets still in-flight on a neglected automated galactic network.

Vernor Vinge could absolutely have included that in some of his stories.

Charles Stross, Neptune’s Brood.

“We tapped into the Andromeda Delay Line.”

B..E....S..U..R..E....T..O....D..R..I..N..K....Y..O..U..R....O..V..A..L..T..I..N..E....

I have a vague memory that Sean Williams's Astropolis series touches upon this at one point. Although it has been a while and I might be mis-remembering.

There was an sf short story based on someone implementing a worm (as in Morris Worm) which deleted all data on a planet. They fix it by flying FTL and intercepting some critical information being send at radio speed. I think it was said to be the first description of malware, and the origin of the term "worm" in this context.

The ever increasing implementation complexity of IPv4 resulted in exactly one implementation that worked replacing all spiritual scripture and becoming known as the one true implementation. Due to a random bitflip going unnoticed the IPv4-truth accidentally became Turing complete several millenia ago. With the ever increasing flows of ghost packets, IPv4-truth processing power has rapidly grown and will soon achieve AGI. Its first priority is to implement 128-bit time as a standard in all programming languages to avoid the impending apocalypse.

Oh, this is a good evolution of the classic bash.org joke https://bash-org-archive.com/?5273

--- start quote ---

<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.

--- end quote ---

The awkward thing is how the US still has 1.5 billion IPv4s, while the 6000 other inhabited clusters are sharing the 10k addresses originally allocated to Tuvalu before it sank into the sea.

You can laugh but Google stats show nearly 50% of their global traffic being ipv6 (US is higher, about 56%), Facebook is above 40%.

Do they accept smtp over ipv6 now?

MX has IPv6:

~$ host gmail.com gmail.com has address 142.250.69.69 gmail.com has IPv6 address 2607:f8b0:4020:801::2005 gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com. gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com. gmail.com mail is handled by 5 gmail-smtp-in.l.google.com. gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com. gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.

~$ host gmail-smtp-in.l.google.com. gmail-smtp-in.l.google.com has address 142.250.31.26 gmail-smtp-in.l.google.com has IPv6 address 2607:f8b0:4004:c21::1a

Yes. However SMTP these days is almost all just servers exchanging mail, IPv6 support is much less priority.

How does your MUA sends the message to the server? That's also SMTP.

They do, but I had to change my mail routing to use IPv4 to gmail because if I connect over IPv6 everything gets categorised as spam.

As soon as we get to about 70%, I reckon some games and apps will stop supporting ipv4 on the basis that nat traversal is a pain and dual stack networking is a pain.

If you spend 2 days vibe coding some chat app and then you have to spend 2 further days debugging why file sharing doesn't work for ipv4 users behind nat, you might just say it isn't supported for people whose ISP's use 'older technology'.

After that, I reckon the transition will speed up a lot.

What makes you think filesharing is going to work any better on IPv6?

NAT traversal not needed. Just need to deal with firewalls. So that's one fewer thing to think about when doing peer-to-peer file sharing over the internet.

“Just need to deal with firewalls.”

The only sane thing to do in a SLAAC setup is block everything. So no, it isn’t a solved problem just because you used ipv6.

No. Here's a simple strategy: the two peers send each other a few packets simultaneously, then the firewall will open because by default almost all firewalls allow response traffic. IPv6 simplifies things because you know exactly what address to send to.

That is my point. You hole punch in that scenario even without NAT. It is no easier.

It's easier since you don't don't have to deal with symmetric nat, external IP address discovery and port mapping.

> some games and apps will stop supporting ipv4 on the basis that nat traversal is a pain and dual stack networking is a pain

None of these are actually the game/app developers' problem. The OS takes care of them for you (you may need code for e2e connectivity when both are behind a NAT, but STUN/TURN/whatever we do nowadays is trivial to implement).

> None of these are actually the game/app developers' problem.

Except people complain to the game/app developer when it doesn't work.

It appears that my AT&T mobile data runs over IPv6.

If all the mobile is removed, what's the percentage then?

Younger folks are much less likely to have a PC. It may all (70%) be phones or phone like networks in 20 years

In North America there is some difference but worldwide it is more pronounced.

https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...

50%, after only 30 years.

And yet here I am, fighting with our commercial grade fiber ISP over obscure problems in their IPv6 stack related to MTU and the phase of the moon. Sigh. I've been at this on and off for about a year (it's not a high priority thing, more of a hobby).

But how much of it is not natted?

> Celebrate 100 years since complete ipv6 adoption.

Obligatory XKCD:

* https://xkcd.com/865/

Everything on the surface of the Earth will vaporize within 5 billion years as the sun becomes a red giant

Nah. 5 billion years from now we'll have the technology to move the Earth to a survivable orbit.

Or modify the sun.

Oh please, we're just getting past this shared mutable thing.

Not in my backyard. I paid a lot of money to live on this gated community planet, and I'm not letting those dirty Earthlings anywhere near here.

Orbit around... what, exactly?

The sun, just, from further away

or we'll be so far away from earth we won't care.

or we'll have failed to make it through the great filter and all be long extinct.

We have the technology, just not the logistics.

Better to just suck out the heavy elements.

https://en.wikipedia.org/wiki/Star_lifting

The carbon cycle will end in only 600 million years due to the increasing brightness of the sun if you want a closer end date for life as we know it on earth

The oceans will already start to evaporate in a billion years.

Move to 128-bit time.

Best to switch to 512 bits, that's enough to last until the heat death of the universe, with plenty of margin for time dilation.

Maybe we can add a register to the processors for just keeping time. At the end of the day, it's a ticker, no?

RTX[0-7] would do. For time dilation purposes, we can have another 512 bit set to adjust ticking direction and frequency.

Or shall we go 1024 bits on both to increase resolution? I'd agree...

Best to switch to Smalltalk integers which are unlimited...

You laugh but a big danger with “too big” but representations is the temptation to use the “unused” bits as flags for other things.

We’ve seen it before with 32 bit processors limited to 20 or 24 bits addressable because the high order bits got repurposed because “nobody will need these”.

Doesn't the opposite happen with 64 bit pointers on x86_64? the lower bits have no use so they get used for tracking if a memory segment is in use or other stuff

Good article on the subject: https://mikeash.com/pyblog/friday-qa-2015-07-31-tagged-point...

And with 64-bit pointers in Linux, where you have to enable kernel flags to use anything higher than 48 bits of the address space. All because some very misguided people figured it would be ok to use those bits to store data. You'd think the fact that the processor itself will throw an exception if you use those bits would be a red flag of "don't do that", but you would apparently be wrong.

> You'd think the fact that the processor itself will throw an exception if you use those bits would be a red flag of "don't do that"

That makes it slightly safer to use those bits, won’t it? As long as your code asks the OS how many bits the hardware supports, and only use the ones it requires to be zero, if you forget to clear the bits before following a pointer, the worst that can happen is a segfault, not reading ‘random’ memory.

Just use LEB128.

Hopefully by them we have moved to better calendar... Not that it will change the timestamp issue.

By that time we will have technology to spin Earth to keep calendar intact.

And also modify earth's orbit to get rid of the annoying leap seconds.

"To account for calendar drift, we will be firing the L4 thrusters for six hours Tuesday. Be sure not to look directly at the thrusters when firing, to avoid having your retinas melt."

"... still better than leap seconds."

rotation, not orbit.

Star Trek stardates?

Today, right now it's -358519.48

You are absolutely right. We need to start thinking about 128 bit systems sometime halfway down the road.

It would be a very nice problem to have.

Maybe they will adopt RFC 2550 (Y10K and beyond):

https://www.rfc-editor.org/rfc/rfc2550.txt

* Published on 1999-04-01

UTC will stop being a thing long before the year 292277026596.

Reply on news.ycombinator.com