Tell HN: Hacker News now supports IPv6 | Hacker News Reader

Tell HN: Hacker News now supports IPv6

555 pointsp1mrx374 comments

My browser just started connecting to Hacker News over IPv6 today:

  $ host news.ycombinator.com
  news.ycombinator.com has address 209.216.230.207
  news.ycombinator.com has IPv6 address 2606:7100:1:67::26

Both IP addresses share the same ASN (M5 Computer Security): https://bgp.he.net/ip/209.216.230.207 https://bgp.he.net/ip/2606:7100:1:67::26

The raw IP address correctly redirects to HN: http://[2606:7100:1:67::26]

Good job so far! Please don't pull a Reddit and turn it off again.

View on HN

Ha! Beat me to it!

For anybody that's curious, the IP-Foo [0] browser extension puts a little 4/6 icon in the address bar to make it clear at a glance which dialect you're speaking for $currentWebPage

[0]: https://github.com/pmarks-net/ipvfoo

cool, but "read and change your data on all websites" is imho not worth the functionality. that seems ripe for takeover by some scammer.

IPvFoo author here. The problem is that there's no way to obtain the (hostname, ip) stream from Chrome/Firefox without requesting the "all websites" permission.

In theory, browser vendors could define a narrowly-scoped permission that only reports (hostname, ip), or roll this functionality into the browser UI, but neither seems likely to happen.

I made IPvFoo to promote IPv6 adoption, and wouldn't consider selling it for less than $10M USD. It probably won't ever be worth that much because it's an easily-cloned utility without a "moat", but it's more rational to set a price than refuse to sell under any circumstances.

The danger with extension acquisitions is malicious buyers, who use their ability to run arbitrary code to steal credit card numbers or credentials, insert or replace ads, run cryptocurrency mining, etc. For malicious purposes number of installations is the important thing, not how clonable the extension is.

$10m could be worth it for a nation state actor targeting a specific high-value individual known to use the extension.

You can do those in private windows, there's separate permission for those: https://support.mozilla.org/en-US/kb/extensions-private-brow...

Miners need the least amount of permissions anyway.

> IPvFoo author here

It makes sense that you would notice the change then :D

Was this a situation where you had to do a double-take? Like, you opened HN today and saw that your extension said IPv6 and for a split second you wondered if your extension had made a mistake? Before seeing that indeed HN has IPv6 now.

I didn't really think it was a mistake, just switched to "Morpheus is fighting Neo!" mode and started collecting evidence, most of which is in the post.

yeah, i appreciate that. my post wasn't meant as a criticism, it's a cool project and i'm happy your extension exists.

i have no reason to think you'd sell out to scammers, but stranger things have happened and for a product whose whole utility to me is "huh, that's cool" it's not worth it. and i thought that was worth highlighting to others. some chrome extension hygeine is always good.

$10M for access to a pool of 100k (and growing) tech-savy users that are harder to hack than gen-pop? You guys, the 100k+, are lucky I'm not made of money.

I appreciate the honesty, and the reality is that most add-on developers have a price; a lot of people would probably sell their add-on for $10M.

But these things auto update. If a government (or even just a moderately big org) really wants to spy on someone, and they determine that said someone uses IPvFoo, $10M isn't a very large price to pay to just get complete access to the target's web browser.

This isn't specific to your add-on in any way, but, well... that seems ripe for takeover by someone nefarious.

If your threat model includes a government...

Which it kinda should? It's not as if governments universally have proven themselves to not do messed up shit and not violate people's privacy

As a member of your country's public society at large, sure (media campaigns, propaganda, government contracts for IT equipment and infrastructure). For individual targeting.. not many people.

TY for making the extension. As someone who uses it daily, you are my saving grace and my go-to for telling when a website has enabled IPv6 or not, if it wasn't you making this post that's how I would have found out HN had enabled it too.

I get fun questions from people when I screenshare and they notice the green "6" or the red "4" and ask about it. Sure it doesn't do anything fancy behind the scenes but that's also what makes it perfect.

Offtopic:

    // Don't waste time rewriting the same tooltip.
    // Don't waste time redrawing the same icon.

Finally someone who understands the basics.

Just wondering, do you expect non-scammers to have the $10m?

No. I expect that I won't sell it because it's worth more to me than anyone else.

> $10M USD

Hah. You take a strong starting position in the negotiations ;)

Thank you for writing this tool. It cheers me up every time I see a green 6.

To determine ipv4/6, do you need to send that hostname and ip off to somewhere to get a response? or can it be done locally without leaving the machine?

It's local. The webRequest API provides an 'ip' field with each request, and the hostname can be extracted from the URL. Once you have an IP address, just check for colons.

https://developer.chrome.com/docs/extensions/reference/api/w...

You can determine that by looking at the value.

IPv4: 123.123.123.123

IPv6: 2001:db8::8a2e:370:7334

Oh yeah. DUH!

ipv6 addresses are different, so they’re easy to distinguish

> roll this functionality into the browser UI,

Is it hard to get patches into firefox? I never tried, just curious.

Just download the repo as a zip file and manually upload it as an extension to your browser.

Note that the top-level manifest.json is for Chrome. To use it with Firefox, you have to copy "manifest/firefox-manifest.json" onto manifest.json first.

Though be warned, after a restart Firefox doesn't re-enable side loaded extensions that were added in the "debug" mode.

Also, Chrome (Google) has a habit of randomly disabling or removing side loaded extensions. I even had a side loaded extension that Google forced removal of because Google deemed it contained malware (which it didn't, I know because I wrote it).

Just read the source code.

Not good enough to protect against the kinds of attacks that OP is warning against. Chrome extensions update automatically and there have been many cases of extensions being purchased by malicious actors who modify the code to be spyware or adware.

You can download the current version and install it manually to get around that. If you do that and read the code you're probably safe.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

So the problem is in the behaviour of the browser, but not the extension.

Read the code, don't update 'till you read the code, don't use the browser which knows better what is good for you.

Seems to me fine grained access controls would go a long way. The extension gets access to specific capabilities. Such as network connectivity. Local extensions have a much smaller blast radius.

In Chromium, you can click on the request in the Network panel and it will show the IP.

I see:

    Remote Address: [2606:7100:1:67::26]:443

When I put that into the url bar:

    https://[2606:7100:1:67::26]/

I also see Hacker News.

As someone who grew up on IPv4, i will miss it, but the leap to 340 undecillion unique addresses is exciting in many ways so i think i can learn to live with this transition. If we ever need more than that, i can't even imagine what that future would look like.

I grew up with IPv4 too but after learning and configuring my network for IPv6 I won't miss v4 at all. It's just so nice having each device with its real IP address rather than some private NAT thing. Then it's just firewall config if you want to run servers etc rather than messing with NAT configs.

Agreed. My favorite part is that you don’t need any special consideration for local/WAN splits in DNS. Your DNS address for your homelab server is the same address on your LAN as it is on the WAN, so your DNS can just be the same. Thus “ssh hostname.fqdn” works whether you’re on the local network or remote, and your packets just automatically stay on your LAN when you’re local (they don’t even have to hit your router… they can directly unicast if you’re on the same switch. No “hairpin NAT” or anything like that needed.)

Doesn't that mean if you move, or if your ISP changes your IP, all your local devices will end up with different addresses?

I have an internal DNS server and it would be annoying if it could randomly break and require me to update all the IPs.

You can add ULA addresses to devices and use those in local DNS. Or just use the automatic link-local ones, One of the best things about IPv6 is support for multiple addresses per host and using them in different contexts.

I stopped maintaining local DNS and use mDNS instead which updates automatically.

I use ULA addresses in my local dns, the global address can change, privacy addresses can cycle and my local DNS keeps working. This also guarantees that the data you are pushing locally stays local since ULAs will never be sent out of the local network.

My local devices end up with new ipv6 addresses daily.

So if I'm checking local server log files to debug a problem that started a few days ago, I can't easily tell where the incoming connections are coming from?

You can configure a static ip if you use IP addresses as an identifier. You can also keep track of who had what ip address.

> My local devices end up with new ipv6 addresses daily.

Isn't that a pain in the butt?

You’d think so, but dns magically works for me. Wish I had a better answer ha ha.

I assume it's possible to prevent machines from changing their IP address? I have a few where DNS cannot reasonably be used and I use raw IP addresses instead.

The last time I looked into this (which was a few years ago), ISPs were allocating blocks containing billions of IPv6 addresses to anyone who paid a nominal sum.

So that vast address space might not last as long as it would seem...

> So that vast address space might not last as long as it would seem...

Have you done the math?

* math property: x^y = x^(a+b) = (x^a )x(x^b )

* IPv4 addresses are 32 bits (2^32 )

* 2^32 ~ 4.3 billion

* So the IPv4 Internet has ~4.3B devices on it

* IPv6 subnets are 64 bits, /64 (2^64 )

So, a IPv6 2^64 subnet is the same as (2^32 )x(2^32 ), which means (4.3B)x(IPv4 Internet). I.e., a single IPv6 subnet can hold the equivalent of four billion (IPv4) Internets.

A second way of thinking about it:

* Stars in the Milky Way: 400 Billion

* Galaxies in the universe: 2 Trillion

So (4x10^11 )x(2x10^12 )=8x10^23 stars in the universe.

* Size of IPv6 address space: 3.4x10^38

Find the ratio between addresses and stars:

* 3.4x10^38 / 8x10^23

IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.

A third way: On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km2. Not counting the oceans, that would be 28 IPv4 addresses per km2 of land.

IPv6 gives 10^17 addresses per mm2 (yes, square millimeter).

In terms of volume, 10^8 IPv6 addresses per mm3 throughout the Earth.

Since you seem to know what you're talking about:

Imagine a scenario where we have nano-bots to perform "repairs" in our bodies or whatever, and obviously each individual nano-bot use TCP over IPv6 because future software developers are also as lazy as us.

Instead of taking paracetamol, people take nano-bot-shots which include (presumably) millions (or even billions?) of nano-bots that we inject into our bodies. However, they disappear after a week (or some other more realistic timeline).

Now, how many people can use these on a monthly basis before we run out of IPv6 addresses?

Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever? This seems like an unlikely scenario, but I'll assume it's just an intellectual exercise and take a stab!

- Total number of /64 subnets available: 2^64

- Total number of humans in this future: Let's say 16 billion (roughly twice what we're at now)

To get the total number of months before we'd run out of /64 subnets, assuming each human is absorbing one every month, we divide the number of /64 subnets by the number of humans:

2^64 / 16 billion =~ 1,152,921,505

Divide by 12 to get the total number of years:

1,152,921,505 / 12 =~ 96,076,792

So by my math, assuming the human population stayed steady at 16 billion (which seems just as absurd as the initial premise) we'd have about 100 million years to figure out how to start reusing some of those old subnets before we started running into trouble.

> Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever?

No, I meant it as "You can reuse the subnet after 1 week + N" basically.

> it's just an intellectual exercise and take a stab!

Indeed it was, and thanks for conjuring a gratifying answer :)

I think this turns out to be a pretty good example of how stupidly big the ipv6 space is. Because it sounds like a big ask until it meets the numbers.

So you want "even billions(!!1!)" of nanobots per allocation. Well I'm lazy, and dynamically allocating a /64 is built right into the protocol. So lets let my medication dynamically allocate out of a /64. How many billions? Billions of billions. So lazy, so sorted.

But of course, I don't want my medication talking to my wife's medication. So lets de-conflict that. In fact, let's de-conflict everyone's medication.

We all know that 32bits is a bit over 4 billion. So 33 bits is going to be a bit over 8 billion. That's enough for now, but it's iffy, so let's go for 34bits, a bit over 16 billion. But in ipv6 world, it's polite to land on a nibble-boundary, so we'll go for 36 to be polite.

I'm going to steal the old allocation for ULA as an example. It was /7, but I'm going to call it /8 because I like round numbers.

So lets have an 8-bit prefix ala ULA. Then an 8bit planet number. Then an 8bit country/healthservice/issuingbody number. Then a 40bit human number, because I ran out of reasons to waste 8's There's our 64bit network number. With 64 bits left for billions of billions of nanobots to dynamically allocate.

The best bit about ipv6 isn't billions, it's that we get to actually structure our networks instead of cramming them into every nook and cranny we can buy.

IPv6 devotes a giant chunk of space to ephemeral link-local connections, if I recall correctly, at least a /64. So you'd need about 10^18 nanobots or so before you start to have to worry about link local address exhaustion.

These do not have to be globally unique, just unique on the local network.

Official assignments are at:

* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...

Currently all public addresses are being assigned out of 2000::/3. The following are reserved for future (public?) use: 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3.

Everything that starts with "f" is a special case, so the vast (vast) majority of address space is cleaved off.

https://xkcd.com/865/

That sure sounds like a lot. But "billions" is less than a /64. Try "sextillions" (/56) or "septillions" (/48). Of course, when the denominator is "undecillions", it becomes clear that this is actually a non-issue.

ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6.

A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.

>ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6. A reasonable sized /32 allocation [...]

The more one digs, the more egregious it seems. If the NETIFY webpage is accurate, it shows that Capital One already had "/32" and "/36" blocks, and yet they also got "/16" : https://www.netify.ai/resources/networks/capital-one

And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation: https://www.arin.net/resources/fees/fee_schedule/

There doesn't seem to be any public transparency of the approval process to explain how a non-ISP company could justify a "/16" block so it just leaves everybody guessing.

John Sweeting from ARIN only confirmed that the "/16" was allocated to Capital One according to policy but he didn't elaborate on the rationale: https://www.mail-archive.com/arin-tech-discuss@arin.net/msg0...

Example reddit discussion : https://old.reddit.com/r/ipv6/comments/17yuqvp/til_capital_o...

> And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation:

For better or worse, you're not; that's for IPv4 /16. For IPv6 /16, it'd be the X-Large service category, so $16,000/year.

And for $256,000/year you can... exhaust the entirety of 2000::/3?

Yeah, that's not okay. Either the price needs to go up a lot or they need to include factors other than money in the allocation criteria.

> they need to include factors other than money in the allocation criteria

They already do, and simply being able to pay the fee does nothing to qualify you for an allocation: https://www.arin.net/participate/policy/nrpm/#6-ipv6

At least, in theory. I'm not going to attempt to defend the Capital One allocation.

Too bad ARIN tickets aren't public - I would love to read the one in which that was justified. Reading NRPM 6.5.2.1, it seems that they must have submitted documentation claiming at least 2^28 distinct serving sites in order to qualify for an assignment that large.

I find the insistence of using /64s everywhere for networks frustrating. Any network larger than a /112 seems crazy, that's already 65k IPs per subnet. A /104 for every normal end user (256 subnets per user), or a /80 for massive companies like Capital One (4 billion subnets) should be more than enough.

There is a really practical reason behind this, and it is called "routers". Due to longest prefix match, you'll end up wasting resources on the networking hardware. And you waste both precious and expensive TCAM and LPM latency for matching the prefixes. So routers do optimize for anything shorter than /64, and have special lookup memory for /64 and /128. But nothing in-between.

This still not justifies a /16 allocation

thankfully I replied to a comment speaking about a tangent (/64s) and not to its parent. /s

Snark aside, very much agreed, and I don't like that they got away with it. It's precisely with the mindset of "we'll have enough" that companies like ford have a /8 or the DoD has more /8s that we can count. And with this mindset we'll run out of IPv6 the same we ran out of IPv4.

That's fair enough, in which case ipv6 is really only a /76 (having more than 1000 hosts on a subnet isn't a great thing, even with no broadcast and arp and other traffic, and /76 allows 4000 on a /64)

Those fanboys going "we'll never run out of 2^128 IPs" are being disingenuous when about 2^59 of them have been burnt straight away (I'd guess most subnets have less than 30 devices)

2^64 subnets is a reasonable number, but when they are handed out like candy that number dwindles quickly. ARIN is allocating the equivalent of a /15 every year. That's fine if it's a constant allocation, there's 100,000 years worth, but if that rate grows, the space will be eaten in a matter of a few decades.

Having a ludicrously large address space is kinda the point of IPv6.

You're not ment to utilize every address assigned to you. Trying to do so will always lead you to situations where you messed up and need to renumerate.

It's not just about the number of devices. Stateless Address Autoconfiguration for example basically needs a /64 subnet.

because it was designed that way. "we need it because we need it".

Except you need at least a /64 for v6 to properly work.

You only need it for SLAAC, and only because SLAAC was made that way.

You only need it because that's how the protocol was designed.

I'd even go out of my way and say that undecillion of IP addresses ought to be enough for anybody.

Bold prediction! Let's see if it holds true in 200 years when every cybernetic cell in your body is individually addressable from the public internet.

This is almost IPv9 (RFC1606)! https://datatracker.ietf.org/doc/html/rfc1606

   The up to 42 deep hierarchy of routing levels built into IPv9 must
   have been one of the key features for its wide deployment. [...]
   As yet, no requirement has been found for levels 40-42, with level 39
   still being used for experimental interrogation of atomic structure
   of components where required.

Of course, it's a 1st April RFC. For those who don't know them, see https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C...: they include thinks like terminals with subliminal messages, IP over pigeons...

98% of all IPv6 addresses will be set aside for self-replicating nanobots and our bodily cells will have to fight over only the remaining 2%.

I'm sure people said exactly this about IPv4 back in the days.

So the funny thing is .. they didn't. They really didn't.

The original numbering plan for IP was that each network number became a /8. Which is how we miraculously ended up with 10/8, because network 10 was ARPANET itself, so 'flag day' left 10/8 vacant.

But back to the point at hand. IP itself is RFC 791, September 1981, nice and famous. The addition of classful networking because 255 network numbers wasn't going to last long, was RFC 790.

The first workaround for IP exhaustion was published before IP. It's been a Known Issue since day negative-one.

Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?

That subnet is large enough to then assign an IP address to every individual atom in that grain of sand.

For comparison, if we wanted to assign every living person on Earth a grain of sand, we would only need a few cubic feet of it (less than 1 cubic meter).

Allowing a credit card company to have a /16 is one way to do it. Do that 65,535 more times and IPv6 is exhausted.

Fair point, but that's politics and bad actors, no standard can survive that.

> Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?

As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.

And when IPv16 finally appears in the future, people will yet again make exactly the same argument.

> As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.

You're ignoring the sheer scale of this question. We don't have enough raw materials on this planet, or likely in the observable universe, to produce enough devices that would consume that many IPs.

We could colonize 1 billion planets.

Each of those planets could have 100 billion people.

Each of those 100 billion people could own 1 billion "things" that could be considered "networked devices".

Each of those "things" could consume 1 billion IPs.

We could have all that, and we would still have 70% of the IPv6 space left.

> The decision to put a 32-bit address space on there was the result of a year’s battle among a bunch of engineers who couldn’t make up their minds about 32, 128 or variable length. And after a year of fighting I said — I’m now at ARPA, I’m running the program, I’m paying for this stuff and using American tax dollars — and I wanted some progress because we didn’t know if this is going to work. So I said 32 bits, it is enough for an experiment, it is 4.3 billion terminations — even the defense department doesn’t need 4.3 billion of anything and it couldn’t afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we’d have an opportunity to do a production version of it. Well — [laughter] — it just escaped! — it got out and people started to use it and then it became a commercial thing.

- https://www.youtube.com/watch?v=mZo69JQoLb8&t=816s

They were contemplating 128 bits addresses all the way back then, but settled on 32 bits as a mere proof of concept that got out of hand.

One use case is private entities squatting on massive ranges that they have no hope of ever practically using, and thereby extorting other people and organizations as the rest of the address space gets massively over-allocated to other uses.

Nanites might give you a good start

Of course we'd all be paperclips long before they need to worry about networking

One of the features of IPv6 is address autoconfiguration, obviating the need for a central authority like DHCP on v4.

However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.

But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.

If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)

I don't understand why getting rid of DHCP is desirable. DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!). Checking "Does my interface have an IP address?" is also a really really useful and quick analogue for "is the gear related to the LAN pretty much working or is something broken/misconfigured?".

As it is, all my interfaces just have these random IPv6 addresses configured which don't work most of the time. I don't get it.

> I don't understand why getting rid of DHCP is desirable.

It's less infrastructure to run, especially with embedded networks.

> DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!).

You are limiting your thinking to macro-scale 'user-managed' devices, as opposed to things like embedded things:

* https://en.wikipedia.org/wiki/Matter_(standard)

FWIW; SLAAC works by setting the local part to the mac address.

So, if you have knowledge of your mac address (which is what you say you are using for DHCP) then you will know the fe80::<> IPv6 IP too, which, while not globally routable is probably what you want based on this comment.

Wait SLAACs aren't globally routable? I thought the whole idea behind IPv6 was to not use NAT?

> Wait SLAACs aren't globally routable?

It is not the host-component of IPv6 that determines routability, it is the prefix.

If you have a link-local prefix (fe80::/10) then it is not global, if it is a private prefix (fc00::/7) then it also may not be global; if it is part of IANA's unicast allocation (2000::/3) it is global (firewall permitting).

There's an education here that unfortunately I don't have the time to give you.

SLAAC is the replacement for DHCP, it provides a local prefix address (fe80::) and optionally (and, crucially: additionally) provides a publicly routable IP if there's a public prefix available.

You can think of the subject being split into two components:

As a base: You will get a local IP

On top: you get DNS/Public routing.

Here's a bit more about how it works: https://www.networkacademy.io/ccna/ipv6/stateless-address-au...

I still haven't figured out how to get these auto-configured addresses into my home network's DNS (or any DNS, for that matter).

It is pretty easy on OPNsense but it's virtually impossible on many other types of routers. Meraki and Asus as two examples of that.

I'm actually running dnsmasq from a FreeBSD host. How would dnsmasq know about the self-configured addresses? I guess I could run DHCPv6, but it's next to impossible to get any kind of prefix delegation going with my ISP anyway. At the moment their router hands out the v6 addresses and I use v4 for dnsmasq.

> However, that only works with a /64 prefix

Well it should be redesigned so it works all the way down to individual addresses.

You can use DHCPv6 instead of SLAAC if you need autoconfiguration on sub-/64 prefixes.

Some systems like android don't support anything but SLAAC

IMHO it means that they are not fully IPv6 compliant. Corporate networks often have DHCPv6 rather than just SLAAC.

There was a proposal for that: https://www.ietf.org/archive/id/draft-mishra-6man-variable-s...

> Well it should be redesigned so it works all the way down to individual addresses.

Why? What's wrong with how it works at the moment?

I actually have the issue where my ISP gives me a single /64 and it makes it difficult to split between multiple LANs.

Published guidance says they're meant to give out at least a /56. I don't know that making autoallocation work on smaller subnets would help with this problem - ISPs that currently give out the smallest possible subnet would probably just switch to whatever the new smallest possible subnet was.

Shitty ISPs will always give you as little as they can get away with. If the software enforces /64, they'll you /64. Raise the limit to /128 and they'll give you /128.

At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.

What do you mean by that? What you do inside your assigned range is completely up to you - you can split that up as you want.

But they aren't all /48s. Upthread there's a post about /16s already being allocated.

ISPs are SUPPOSED to allocate a /64 for a single customer. Mine does, so I have 4.5 billion available addresses within my 2001:4653:nnnn:nnnn::/64 prefix...

> ISPs are SUPPOSED to allocate a /64 for a single customer.

Weren't they supposed to allocate a /48? Or did that change while I wasn't looking?

> Or did that change while I wasn't looking?

Yes: https://datatracker.ietf.org/doc/html/rfc6177

  2^32 is ~4.3*10^9

  2^64 = 2^32 * 2^32 , so quite a bit more

Billions of addresses might seem like a lot, but every IPv6 network has at least 2^64 addresses and it doesn't make much sense (to me) to give any customer less than one network.

(Maybe you meant billions of /64 blocks? ISPs could be providing a /32 ≈ 4 billion /64 blocks, though there still are 2 billion of those in the entire IPv6 space)

The space currently assigned to globally routable addresses is 1/8th of the v6 address space. Over 50% of the addressable space is currently reserved.

The numbers are frankly mind-bending. Even if we we make a complete pigs ear of assigning billions of IPs to billions of networks in the current /3, we have space for more than one do-over.

But I do believe there's a higher chance the next /3 will be assigned to Mars.

We never learn

I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.

And the IPv8 would be 0.0.0.0.1.2.3.4 whenever we need it, but probably not for a long time

When I saw all the double-colons and slashes and monstrosities like f00f:00f:::ea//dead::beef/3 I just kept using IPv4.

I can't even remember Google's IPv6 DNS ffs. 8.8.8.8 was easy to remember. Now it's got some hex bullshit in it and a double colon thrown in somewhere.

Exactly this misconception comes up (often multiple times) every time there’s a discussion about IPv6 on HN.

No, it’s not possible without running into the exact same problems that we had with IPv6 (which actually has various compatibility mechanisms, to the point where now some mobile networks are IPv6 only but still work to let people access IPv4).

The problem with your proposal is the same issue we have now - something that only talks the old protocol can’t possibly talk to something in the new protocol (without the same kind of hacks we use with IPv6 like NAT64/464XLAT), since IP addresses in headers are fixed sized. Which also means that any router in the middle can’t possibly route packets to networks with the expanded addresses. So we have the exact same issue - everything needs to be upgraded to deal with your new scheme, but unless that all happens on the one same day, you need to be able to deal with the old addresses. So you need dual stack, just like with IPv6 until everything is transitioned.

So basically all you’d have with this kind of proposal is exactly the same problems, but it would be more confusing why older devices can’t talk to the newer devices since the addresses would look very similar!

There are endless protocols and methods which embed ipv4 addresses to ipv6 ones. RFC 4291 specifies exactly what you want, all-zero prefix+ipv4 address: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5

See also the text representation section: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.2

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are

      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:

         0:0:0:0:0:0:13.1.68.3

         0:0:0:0:0:FFFF:129.144.52.38

      or in compressed form:

         ::13.1.68.3

         ::FFFF:129.144.52.38

So in addition to having the addresses embedded on binary level, you even have that text notation that uses traditional ipv4 dot-notation!

You might ask why they are not more prevalent, but then you will find the practical issues that various transition mechanisms are attempting to solve.

Another person who does not understand IPv4.

IPv4 isn't a text based protocol where IP addresses are parsed like DNS. It's a binary protocol where addresses are recorded in binary and adding more address space WOULD BE A BREAKING CHANGE.

For a practical demonstration: That's the reason decimal IPs work, too - i.e. http://3520653007/ is the same as http://209.216.230.207/ (and both will go to HN) - it's all just nice formating for our human brains.

Nothing would stop us from formatting IPv6 the IPv4 way except the monstrous length of the resulting address.

Wow learned something new today. What's interesting is that the decimal representation looks more like a phone number which people would be used to. Interesting that IP addresses as they are written today was the format that won, as a kid before learning how computers worked I always found it weird how 255 was the highest number in each group.

Its often challenging enough for people to do CIDR subnet calculations in their head when its broken out into octets. I'd have just given up on networking entirely if the standard was to use decimal notation.

You can even make it funnier by having it look like a floating point number: http://209.14214863/

Or a strange number with two decimal parts: http://209.216.59087/

My whole life I went without knowing decimal IPs were a thing..

There's more than just decimal .... https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4...

A 32-bit number is a 32-bit number. Whether you represent it in dot notation, hex or decimal.

Not at all. We could have taken one of the unassigned /8's at the time and allocated it to v6 transitional addressing (the failure to address 4->6 reachability is IMO why v6 failed). For the sake of this example lets use 53.0.0.0/8. All new addresses start with 00110101 followed by the first three bytes of the new v6 prefix. The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.

Now your border router can announce your assigned transitional prefix, i.e. 53.32.122.91/32, and is responsible for routing packets to a NAT gateway that knows both v4 and v6 and rewrites packets seamlessly each way.

What we are left with is a scheme that allows v6 to exist on top of v4 and continue working across the existing internet, and the only people who need to worry about it or upgrade anything are the ones who need more address space.

But instead they followed the model of baking in every stakeholders random pet project into v6 to get consensus in the hopes of forcing adoption. They put letters in the middle of numbers, and expected us to not hate it like algebra.

> They put letters in the middle of numbers

If you prefer, you could write an IPv6 address in dotted-decimal notation just like an IPv4 address, or an IPv4 in hexadecimal notation like an IPv6 address. It's just 128 (IPv6) or 32 (IPv4) bits of data after all, the representation is completely independent of the protocol.

For example, you can also reach HN through its IPv4 address by writing http://3520653007/ or http://0xD1D8E6CF/.

> The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.

Your proposal, as usual for these kinds of proposals, fails to consider how would an "old world" endpoint talk to a "new world" endpoint. An "old world" endpoint wouldn't know about these "additional 5 bytes", and would both send packets without them to "new world" endpoints (confusing them) and treat them as data bytes when receiving from "new world" endpoints. The only solution would be to upgrade all the computers on the "old world" first, but once you have to do that you could move them all to the "new world" instead.

If what you want is just the addressing (for instance, you already have 192.0.2.1, and want to use it for IPv6 without needing to obtain an IPv6 address first), there's already 6to4, which has most of the properties you want: it exists on top of IPv4, your router announces the IPv4 prefix, and IPv6 packets sent to it are transparently routed to a relay router which encapsulates them inside IPv4 packets destined to that IPv4 address (in the other direction, your encapsulated packets are sent to a relay router which extracts the IPv6 packet and forwards it). I've used this in the past to give full IPv6 connectivity to a site which had only a single IPv4 address, and it worked well.

I address that. Old hosts and networks only know about the first part of the address and the rest of the address resides in the data section so a new application can run on an old host even. When you cross from an old to a new network, the router can hand packets to a side box that runs CGNAT. This allows for new hosts and networks to talk to old without having to include their full address in the data payload.

Think of it like the mail service. For the majority of the journey your letter is only routed based on the first 3 digits of the zip code. When it reaches the last mile sorting facilities is when the full address becomes relevant.

Your scheme already exists, although instead of using the first octet of the IP address it uses a 41 in the protocol field, so it doesn't need to eat an entire /8. Routers can see the 41 as a flag and then read the v6 address from the beginning of the packet payload.

You haven't managed to suggest anything that v6 doesn't already do, or anything that would solve any of the problems v6 has when doing it. I'm not sure you even noticed the problems, yet you think you can throw stones at the v6 people, who not only noticed the problems but had to solve them too?

Throw that packet at a non-v6 router and let me know what happens. v6 could have been an overlay extension to solve the address space issue without the migration complexities.

We are now 26 years in and v6 has only gotten serious adoption because mobile carriers came along too late in the game to get enough number resources.

That's not what GP said.

Of course IPv4 devices wouldn't be able to use IPv6 addresses, that would be impossible. But it is possible to "keep" IPv4 addresses, just make a.b.c.d to correspond 0.0.a.b.c.d.

First of all, the 4 in IPv4 has nothing to do with its addresses typically being represented in dotted 4-octett notation. That's a coincidence. Each address is a 32 bit number, that's it. Early versions of IPv4 as well as some of the experimental IPv3 drafts actually used 128 bits. In IPv6 there are 128 bits for each address. Nothing to do with 6, which is just a version number.

Second, IPv6 is not just about addressing, it's a new protocol. Many things are different in IPv6, lots make much more sense. The header structure is different. Etc etc. The address space and notation are just the most visible aspects. But it's like comparing IRC and Signal. It's not just about user names, it's a different protocol.

Third, there are embeddings of the IPv4 address space into the IPv6 address space. For example ::ffff:192.0.2.128. Note the mix in notation. This is a valid IPv6 address! Perhaps a bit more cumbersome to write than your suggestion, but for technical reasons it was preferred to keep things syntactically unambiguous (that it's an IPv6 address).

Source: I work at a large router vendor, in the routing team.

Also, none of this is secret. Just read the Wikipedia page. I'm slightly shocked how a tech forum supposedly full of hackers is posting so much half truths and plain wrong information. It's all easily available and understandable, and it's not like we're discussing neurosurgery or epidemiology where we're all amateurs.

You and Plasmoid completely misunderstood dheera and me. I failed to clarify this misunderstanding explicitly (I still don't see where does it come from), so I do it now.

> I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.

As you can see, dheera did not state that IPv4 or IPv6 work with strings. They just said that they wished/expected the trivial extension of the IPv4 protocol, with the same notation, and preserving the existing IPv4 addresses. (These are 2 distinct wishes.) Acknowledging that this did not happen.

Nor dheera nor me posted any half truth or plain wrong information.

> the trivial extension of the IPv4 protocol

It wouldn't be trivial in practice. You'd still end up needing to replace everything in between. And if you're going to replace everything in between, you might as well upgrade it to something much larger instead of taking little half steps that will need to be repeated again and again.

> preserving the existing IPv4 addresses

But it wouldn't really in the end. 0.0.1.2.3.4 is still a different address than 1.2.3.4. You'd still end up needing to translate 0.0.1.2.3.4 to 1.2.3.4, aka a 6to4 tunnel. So, you're in the same place in the end as where we are with the current IPv6, just with only a baby step in changes that will probably need to be upgraded again in the future.

64:ff9b::/96 is allocated for NAT64 - and most US mobile carriers use this as most Android and iOS phones use IPv6 only APNs with DNS64 and 464XLAT.

It comes down to user experience.

How many people managing networks who knew their ip addresses by heart and typed it regularly for all kind of tasks were put off by the new format and decided, consciously or not, to wait until "I really have to deal with it"?

Some people get really angry when you point that out ;)

Good thing for IPv6 it didn't really have any competitor (except IPv4).

2a09:: 2a11:: and 2409:: are even shorter than 8.8.8.8, though not quite as memorable.

I'm not recommending those DNS servers, just highlighting that "vanity" IPv6 addresses exist now. It's possible that 2222:: or 3333:: could be allocated someday.

Related: <https://www.sprint.net/>'s IP address was 2600:: for many years, but they sadly started using a DDoS mitigation service with different IPs.

Technically it's just 128 bits, it doesn't matter how you represent it. I've written this IPv4ES solution, which allows you to use 128 bit addresses using IPv4 format.

https://www.sami-lehtinen.net/blog/ipv4es-the-perfect-soluti...

Huh? IPv6 does have backwards-compatible-ish notation for writing IPv4 addresses. To take your example: 1.2.3.4 would be ::ffff:1.2.3.4, the 96-bit prefix indicated by ::ffff: is where all of the IPv4 addresses live in the larger IPv6 space.

If your issue is with the use of colons at all, they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.

> they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.

Wait until you try to write an IPv6 address with a port number in standard notation.

Usually IPv6 addresses are enclosed in square brackets when a port number is involved. But it's true that in many configuration files IPv6s are a nightmare to put in, especially because you never remember what syntax you have to use: sometimes you even have to duplicate semicolons (that's what Exim does...). But I think this is rather a convention problem for the config files, rather a problem of IPv6 addresses themselves.

The IPv6 people must have known that : was a common way to separate IPv4 and port numbers. IPv6 was standardized 4 years after the URL format which used a colon to denote a port number.

Makes sense, the choice of the colon is a bit unfortunate.

and people are wondering why v6 never took off...

My concern is that this is an accidental part of an unrelated migration and will quickly be disabled because of some internal IP filtering/banning tool that was only ever written to work with IPv4.

Hey, my account works again... >:)

Technically the goal of enabling IPv6 can be done through Cloudflare as well, which they enabled a few days ago. I wonder why they turned it off and are back to directly serving traffic.

They put it behind CF specifically in response to a DOS attack [0]

[0] https://news.ycombinator.com/item?id=38939559

Yea. I noticed that too. Got one or two CF warnings when visiting last week.

Almost ten years after I asked! :)

https://news.ycombinator.com/item?id=7847368

Awesome!

Does ipv6 result in higher latencies? I could see larger addresses increasing latency, but then again I could also see a more efficient protocol resulting in lower net latency. I should probably read a book describing the differences.

Real-world latency is impacted by configuration and hardware (e.g. your ISP may have different routes for IPv6 that can be either better or worse, it can be handled by different routers with different performance, IPv4 traffic may be going through CGNAT, PPPoE concentrators, etc) that dwarf any theoretical differences.

Google's IPv6 stats also measure latency compared to IPv4 and in most countries IPv6 has lower latency (e.g. in the US on average you get 10ms lower latency with IPv6). When this chart was new it was mostly the other way around, with early IPv6 implementations being poor https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Real world performance differences between v4 and v6 are more likely to be influenced by different routing and network manipulation for v4 vs v6 than the larger address size.

If your v4 goes through NAT and v6 doesn't, that's a big thing.

If you have different peering and transit providers in v4 and v6, that's a big thing.

If overhead from address sizes was really a big deal, we'd see work to push larger MTUs and working MTU discovery, but that kind of stalled a while ago. 1500 works for a lot of people, and many major sites drop effective MTU by 20 or so and that makes more things work, and then it gets swept under the rug. (OTOH, I think Android may have finally gotten MTU probing enabled after many years of shipping it disabled; Apple has had very effective probing, at least on iOS for a long time)

The address space has very little effect in the real world. Other latencies far outweigh anything measurable by having slightly more bits in the address.

Eg: Sometimes IPv6 is faster due to routing differences.

That makes sense. I'm very curious about real-world studies. As a gamer, I'm especially interested in the affect ipv6 has on UDP for real time gaming applications. That's an area where even 5ms can have an enormous affect on the experience.

That's a very interesting case, as UDP is very reliant on MTU. If the IPv6 headers take out more space from the ethernet frame, that leaves less space for the UDP payload. Which means that a UDP payload which was at the limit for IPv4 on the typical MTU needs to be fragmented into two IPv6 packets, which will likely increase latency quite significantly.

However, this will depend on each specific game, if they are using all the available space or not. If they're sending 200 byte datagrams, they shouldn't see any difference.

On the flipside, IPv6 has a larger minimum MTU than IPv4, so it could happen that your maximum UDP payload actually goes up when switching to IPv6. So, if the game previously had to send 5 packets to do an update, it might be able to send only 3 when it can rely on IPv6, so maybe latency actually significantly improves.

If you try "ping" and "ping6" towards a multi-protocol host, you see both send 64 bytes each, so while v6 source and destination addresses take up lots of extra space, the v6 IP packets have less of the "this part could be useful for tcp" which means icmp pings can be of the same size, even though the two addresses eat up lots more bytes.

Not sure if the same goes for game UDP packets, but the optional header stuff in v6 IP packets means more of it goes to the useful parts of the payload and less to "the sum of all protocol bits and flags that is not used by all traffic".

This is straight up wrong. An IPv4 ICMP echo request over ethernet uses a minimum of 42 bytes, the same request with IPv6 uses 62. The ethernet frame is 14 bytes and the ICMP echo is 8 bytes for both packets, the difference is that the IPv4 header uses 20 bytes where IPv6 uses 40.

Anecdotally, my ping to HN is consistently 166ms with either protocol. I doubt an extra 20 bytes is going to make any meaningful difference to latency, but I'll leave that for the game devs to find out.

There is nothing in the IPv4 header that is only useful for TCP, especially not in the parts removed from IPv6. Overall the IPv6 header gets rid of the 4 bytes of fields used for fragmentation, and 2 bytes used for the checksum. Fragmentation was never used for TCP in any sane implementation (as TCP can do fragmentation at the TCP layer), and the checksum were fully redundant for TCP. For UDP, the checksum used to be optional, but is now required. So, for an optimized implementation, the checksum removal isn't even a win for UDP, as it has just moved from the IP layer to the UDP layer.

So, we have added 24 bytes to the header because of the address difference, and removed 4 bytes from other places.

Now again, there are many differences between IPv4 and v6 that are much more relevant to latency than this extra header overhead. But it is a real overhead, there is no extra scope for payload. Your observation with ping is just wrong (most likely both versions are just padding the packets up to 64 bytes by default).

If you look at Googles IPv6 statistics the latency seems to be lower with IPv6 in almost all countries: https://www.google.com/intl/de/ipv6/statistics.html#tab=per-...

It could but there have been some reports of lower latency, too:

https://www.youtube.com/watch?v=An7s25FSK0U

This is an area you want to measure carefully because some of the older reports about IPv6 being slower were artifacts of old hardware limitations or under-optimized software which are no longer relevant.

Facebook tested it and IPv6 resulted lower latencies: https://www.internetsociety.org/blog/2015/04/facebook-news-f...

It shouldn't. There is no checksum in header so that is one thing that doesn't need to be calculated, even if it can be done in hardware. And more efficient routing should mean smaller tables to lookup things from so being faster.

Possibly due to routing differences on the path to your service, but not due to the protocol itself. Definitely not due to the address size. Beyond your local equipment, that switching normally happens in hardware.

Verizon Fios recently rolled out IPv6 last year and I swear IPv6 traffic is deprioritized. Sometimes it just cuts out entirely.

Sounds like a technical problem. I don't see any reason they should de-prioritize IPv6 traffic...

Agreed, I don't think it's intentional. It feels like at peak times, some component of their IPv6 infra gets maxed out.

If they have separate infra for IPv6 (but why?) and it's undersized compared to IPv4, it would totally make sense to observe that.

IIRC they disabled it again because the ONTs they have deployed have a firmware bug.

>I could see larger addresses increasing latency

???

Several additional bytes over millions of packets where the data frame is ~10bytes seems potentially significant. I'm less interested in HTTP

20 bytes / 1 Gbps = 160 ns per hop. That's 0.016 ms additional latency over 100 hops.

On the internet, most links are faster than 1 Gbps and most paths are shorter than 100 hops, so that's a conservative estimate.

If you're sending lots of 10-byte payloads, then IPv6 requires (40+10)/(20+10)=166% as much network capacity, but are you really filling up an expensive link with VoIP traffic?

NAT44 has a much larger effect on latency than 16 byte addresses.

In theory, any impact from longer addresses would be outweighed by the benefit of the shorter non-CIDR routing table (and in turn that should be outweighed by avoiding NAT, and that should be outweighed by avoiding CGNAT). (Plus with most systems being natively 64-bit these days, that impact should be 0 - the routable part of an IPv6 address is 64 bits, and comparing a 64-bit value is no harder than comparing a 32-bit value).

In practice IPv6 is newer, which has good and bad sides; IPv6 routing paths are more likely to be using newer (and therefore faster) equipment, but there's also a bigger risk of someone making a mistake that messes up your routing/latency, particularly if your ISP hasn't been doing IPv6 for very long.

> My browser just started connecting to Hacker News over IPv6 today

If you don't mind me asking, how did you notice that?

IPvFoo turned green.

Does anyone know why the TTL is set to 1 on both A and AAAA?

The usual reason for that is DNS load balancing.

HN seem to be served from a single IPv4 and IPv6, so it might not be the case.

Maybe they like paying AWS. ¯\_(ツ)_/¯

I think I created my first IPv6 tunnel in 1998 or 1999. Not holding my breath. For as fast as everything technology seems to move, the basic building blocks of TCP and DNS evolve very, very slowly, if at all. I wonder if there's a genuine lack of interest all around or if there are business interests at stake to prevent people from having their own routable IP addresses and facilitate peer-to-peer networking.

I'm surprised it just got implemented! Since IPv6 is so popular and common nowadays.

My previous provider, I think largest in The Netherlands, ziggo rolled it out quite okay. Now I moved and switched providers, to much faster 1 Gbit (can go up to 8gbit but I dont know what to do with that yet until I have a 32K tv maybe) symmetric, but no idea when they will plan to roll out IPv6 on this network. I cannot say I really miss it, but have to admit my internet feels a bit incomplete :)

so I wish it was even more popular than you state. :D

Well, this exactly explains why HN's site has become so unreliable for me.

As soon as this post appeared, I began receiving timeouts. 90% of the time, the front page won't load, the host won't respond.

I have no troubles with any other IPv4 or IPv6 sites. My home network has been running IPv6 for about 8 years, since my ISP enabled it and I worked out some good router settings.

I routinely verify that all 3 of my devices are preferring IPv6. These timeouts are not occurring on my Android 11 phone, only on my Chromebook for now. Windows 10 Pro, not tested.

Okay, I'm looking into this, and my router was stuck in a "6to4 tunnel" configuration with local address assignment 2002:*

This is undesirable for several reasons, but that's what it picked up with "Auto Detect" and "Auto Config". I toggled settings a few times and regained a 2600:* "real IPv6" delegation.

Surprising hate about IPv6 here despite most of us using commercial internet services where the last leg to our routers is in fact IPv6 including comcast wifi routers....

It's about like a back end geek not knowing how to do loopbacks with their router....sheesh!

What a fun bit of news, thanks to whoever manages the site infrastructure!

I often wish that there had been a way to politically make 240/4 and 0/8 commonly available. But in part I drove those projects to annoy the IPv6 crowd into action.

I think the IPv6 crowd is already decently in action, hence vast swaths of the internet and mobile network already migrated (some on the mobile even without dual stack). What's needed for more IPv6 adoption is continued annoyance felt by the IPv4 crowd to want to bother migrating to any other long term solution. That's required a lot more time than most probably expected but it has been happening, IPv4 has become more and more difficult to use. Throwing in things like "Look IPv4 crowd, there are ways to extend IPv4 for some more years again without the pain of going to multi-layered NAT" is about the exact opposite of the kind of call to action needed.

Either way though, the inherent value in the technology is what has to drive the adoption and the value is already there it's just a matter of IPv4's value still holding well enough for now. As such I don't inherently mind 0/8 being available on Linux these days and wouldn't inherently mind 240/4 either but a completely separate set of "yes, you can configure that address but the problem is with getting between there and here not accepting it" is a bit disappointing for just another short term response to the problem.

Unrelated but kickass work on packet scheduling btw.

I'm still a bit miffed about the Linux kernel change that broke my unit test expecting connect(0.0.0.1) to fail fast.

That's great news, but I'd only say that IPv6 has actually made it when HN switches off their IPv4 address.

How does website support ipv6 without an isp and routers supporting it? You mean hacker news allows IPV6?

browsers cant even open ipv6 ips in the address bar. this makes debugging local services annoying sometimes

Firefox will open this. http://[2606:7100:1:67::26]/

i stand corrected, this is good news thank you

I'm curious why we need the square brackets.

URLs use : to separate the IP and port. There needs to be some way to disambiguate that from the colons in the address.

But if a URL has more than one colon, can't you assume is an IPv6 address?

You can't tell if there's a port or not, e.g. http://2001:db8::1:8080/. Is that 2001:db8::1 or 2001:db8::1:8080?

To disambiguate between the IP and port numbers

Next is TLS 1.3 support, hopefully :)

# openssl s_client -connect news.ycombinator .com:443 -tls1_3 CONNECTED(00000003) 4160736388:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1562:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 244 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported No ALPN negotiated Early data was not sent Verify return code: 0 (ok)

It was briefly turned on years ago and then turned off. I guess it broke the website for those behind corporate MITM boxes.

There's a lot of websites out there that does TLS 1.3. Surely not an issue for MITM boxes? Otherwise they wouldn't be able to access much...

Maybe that wasn't true years ago?

Should be able to support both. Client can negotiate between either TLS v1.2 and TLS v1.3. Server has to support 1.3 though.

I am so surprised by the hate for IPv6 in this thread.

I have been deploying IPv6 for more than ten years and it really improve many situations (beside larger addresses).

I have to admit, there is a learning curve. But I want to encourage everybody involved in configuring computers to learn.

Also I want to rent about Cisco not using /64 for link local by default, thus being incompatible with BSD systems. Link local must be /64.

>I am so surprised by the hate for IPv6 in this thread.

I find that HN views IPv6 noticeably more harshly than many other communities I have been a part of (e.g. networking subreddits and gaming communities). I am curious of the reason behind this.

Networking communities understand the way it works and the improvements it's making.

Gamers understand the consequences of not having it when they want to play with their friend but both are behind CGNAT and they can only play games with a server run by someone else and not any that use P2P multiplayer.

HN users can afford the $2/month/server that AWS or whoever charges today and besides your standard SPA + REST API doesn't really care how many layers of NAT and proxies it's behind.

Developers who don’t care to learn how/why things work, have gone by without it, and are upset that they gotta learn more now because it works differently.

I just hope that people won't repeat the same "I wish IPv6 were just IPv4 with extra octets" viewpoint again...

The use of hex is very helpful when you're calculating subnets. You want a /48 prefix? Just take the first 3 hextets. /56? First 3 and a half hextets. /64? First 4 hextets.

> I just hope that people won't repeat the same "I wish IPv6 were just IPv4 with extra octets" viewpoint again...

The new Godwin's Law, any discussion about IPv6 will inevitably lead to someone suggesting IPv4 with extra octets.

The thread posted yesterday about Czech Republic's IPv4 deprecation plans had at least a comment about IPv4 with extras octets. I am pretty sure that even once IPv4 will be fully dead and replaced by v6, people will still rant about that.

This is an excellent point because entire tools exist with ipv4 to calculate subnets and unless you do base math all the time you’re usually using them to figure out stuff like CIDR overlaps

I think it’s a bit more nuanced than that. The UX of IPv6 is still decidedly inferior. Typing a curl command etc or in general manually typing and remembering IPs is decidedly more difficult with IPv6 vs IPv4. I think IPv6 needs either a killer command line tool or aliasing scheme to overcome that stigma.

The aliasing scheme is called DNS.

Clearly that is not sufficient enough for a variety of reasons else we wouldn’t be having this conversation in the first place

If "IPv6 addresses are harder to type or remember" is the worst thing that happens during the transition to IPv6 then I'd call the whole thing an unquestionable success, given that there were numerous far more important things that could have gone wrong or ended up worse but didn't.

DNS exists to solve the problem of people not having to remember or type IP addresses. This is true regardless of whether you are talking about IPv4 or IPv6.

What problem is not solved by various DNS and local-addressing options, but is solvable by some other aliasing scheme that isn't DNS under another name, and can you outline how a better aliasing scheme would work?

Background and current options, as I'm aware of them:

"IPv6 addresses are too difficult" objectors don't seem to want a solution to the ease-of-use problem that leverages aliases, because DNS is that. They want the ease of typing in IPv4 addresses without any overhead of setting up alias mappings or trusting local hosts' ideas of their own names. That's not possible, in general, with an addressing scheme that's 4x as big. The standard representation has tried to improve things with hex instead of decimal and collapsing the longest run of 0-fields. It could have used a higher base than 16 [1], but that would slow visual spot-recognition of an address. It could have dispensed with all the ':' chars, but that would prevent collapsing addresses and make chunking more difficult.

DNS as an aliasing scheme has many administrative forms. It can be configured per-machine with /etc/hosts (copied around manually, or with scripted or configuration management tools); on a trusted local network with mdns and ip autoassignment, if the network is trustworthy enough; or manually with a full-fledged DNS server, either private or public. More complex network environments leverage tooling to make DNS as painless as possible. The mappings still have to be configured and managed somewhere, even if that's separately per host via what hostname they each think they have.

It's also possible to assign stable, short local addresses that can be remembered and typed easily roughly on par with v4 addresses (10.0.x.1 vs fc00::x:1, which becomes shorter than IPv4 for x==0).

[1] See RFC 1924. Who wouldn't love to use addresses in the form of "4)+k&C#VzJ4br>0wv%Yp" ?

I'll bite: Can you please point me to a resource that explains it clearly, with examples?

My reason: IPv6 failed to fulfill its original objective.

Looks pretty successful to me. They increased the address size. People are lazy though and decided to keep v4.

Successful would be when we don't need to rely on IPv4 addresses anymore. IPv6 hasn't done anything remotely successful in this realm.

I have deployed personal servers that are IPv6 only that's at least a handful of v4 addresses saved / v6 addresses used

That's great, let me know when you can use the Internet without any IPv4 addresses involved (including upstream).

Which is?

Literally the one job it had, to prevent address depletion on the Internet. Just to be clear, we're talking about the Internet here, and not some IPv6 island.

I don't get you. We are running dual stack for the time being, and indeed we cannot solve address depletion this way, but that doesn't mean we are doing it forever.

At some point -- maybe when 60%, 70%, or 80%, or 90% of the Internet is running on IPv6 -- Internet services at a large scale will begin to deem IPv4 as a liability, and drop IPv4 support along with the addresses they are holding.

I am not talking about a distant future either. We already have IPv6-only servers up and running, mine included, and we haven't even reached the 50% milestone. In a way, the existence of IPv6-only servers meant that IPv6 is _already_ preventing IPv4 address depletion, because those servers would otherwise have to compete for IPv4 addresses with the other servers too.

Furthermore, I find "I hate IPv6 because it hasn't eliminated IPv4" a really weird opinion (it's not exactly what you said, but it is how I interpret your first few comments combined) because it's sort of recursive: hate IPv6 -> continues to use IPv4 -> IPv6 is unable to eliminate IPv4 -> hate IPv6??? Perhaps you can elaborate on it further, but I don't think it will be agreeable either way.

IPng was meant to avert the IPv4 address exhaustion crisis. IPv6 was chosen as the way forward. A transition group (ngtrans) was formed and instead of taking the time to consider how to integrate IPv6 into the existing landscape it decided to create a separate island. We now have a hodgepodge of transition plans and umpteen different transition mechanisms of which none make IPv6 first class.

What do I mean by making IPv6 first class? Basically a transition plan/mechanism where IPv6 is interoperable with IPv4. This was one of the primary considerations at the time when IPng were still deciding, where other contenders at the time had a better transition plan story. Instead the IPng group chose the technology that didn't have any transition plan because they liked the shiny new features that were irrelevant to averting the address exhaustion situation. Their failure to address the transition back then is why we're in this IPv6 adoption bottleneck.

Because a lot of us have non simple networks that are also not complex enough to warrant whatever the enterprise design commitee designed for ipv6.

IPv6 will rid us from the abomination of domestic NAT.

IPv6 will, finally, enabled the real internet: all p2p protocols will start to work seamlessly. I am thinking a super simple no-dns IP (audio|video) phone protocol listening only on tcp 1 port, new bittorrent like protocol for live streaming, etc.

Since IPv6 has been almost everywhere in my country for years: enjoying ssh session everywhere (ipv6 mobile internet), without any domestic NAT to configure.

But, still... steam... github... and some "rogue" (:P) smtp servers.

That said for HN, where is the champagne?

Those of us who were supporting Windows machines in the ‘00s remember when 100% of Windows machines not behind NAT were pwned in minutes, while those with NAT were fine indefinitely. Should a firewall have been doing that job? Yes. Were firewalls doing that job, in practice? No, NAT did, and it was very, very effective.

I have… concerns about removing NAT from everyone’s house now that IOT is a thing. Could it be done safely? Yes. Will it? Signs point to no.

Have you looked at what's actually getting deployed? It's mostly no NAT and firewalls, so the signs actually seem to be pointing to "yes".

Even without a firewall, a /64 is an extremely large amount of space. It's nearly impossible to find active hosts by port scanning, compared to v4 where it's trivial to scan the entire address space. We won't end up in the same situation we were in on v4 back when nobody used firewalls, and that's not just because our networks mostly have firewalls these days.

> IPv6 will rid us from the abomination of domestic NAT.

But won't that also have disadvantages? NAT obscures which natural person is responsible for any given household traffic, which makes user tracking and surveillance harder.

> obscures which natural person is responsible for any given household traffic

IPv6 has roughly the same level of privacy; your client device's IPv6 address changes every few hours. Yes there's a minor loss since an association can be made during those hours, but arguably with the generally low number of people sharing a household internet connection I don't think it's a huge difference.

If mobile internet carriers get a specific IPv6 address slice and do what they already do with phone numbers, you could have a mobile non-changing IPv6 routed roughly efficiently, that globally.

Actually, this should be a base service of mobile internet. The various carrier peerings will define how "efficiently" your traffic is routed (realtime audio/video...).

The blocker is the billing scheme I guess (as usual...).

You're kidding yourself if you think NAT was obstructing data collecting and targeting in any way. Browser fingerprinting makes it a complete non-issue.

Is it possible for me, or worse, a normal person, to claim or request an ipv6 address that they can keep and use like a phone number? I'm used to dynamic allocation for residential ipv4 addresses and never bothered to beg ARIN for some or rent since from an ISP. Having an address you could keep and bring with you would be great and avoid a lot of the difficulties of DNS.

Hurricane Electric gives out free ipv6 blocks that you can assign however you want.

I get an ipv6 for my phone through Wireguard that way.

Theoretically possible? Yes: https://chown.me/blog/getting-my-own-asn

A good idea? No.

IP addresses are used for routing. Every provider-independent block of addresses needs its own entry in the global routing tables, which are stored on basically every BGP router in the world. There's a limit to the size of these tables, as they need to be stored in special TCAM memory.

Note that IPv4 currently has many more routes than IPv6 not only due to higher adoption, but also due to higher fragmentation: some providers are obtaining many small non-consecutive blocks from different sources (buying addresses wherever they are cheapest), which results in a large number of routing entries. The increase in the overall table size means all other ISPs have to buy new hardware sooner than they would have without the increase caused by fragmentation. Everyone having their own personal address block would cause even worse fragmentation issues.

An IP is not a global phone number. You cannot port the same "number" from one carrier to another.

If we want that, global orgs in charge of the global phone number mapping must coordinate around some slice of the IPv6 address space (what they already do with international roaming of phone numbers). This will be very hard to operate safely, very probably.

There remain the trappings of what was designed to be static IPv6 addresses that would dynamically route to the network that device was - https://en.wikipedia.org/wiki/Mobile_IP

I don't know if it's actually being used. IIRC since then everything has moved to a higher layer.

I cannot tell neither how things would work in that IPv6 address slice, but "peer synced" sub-slices would be needed.

Like the siblings said, Provider independent IP assignments are available, for v4 and v6 (although to get a v4 assignment in many jurisdictions, you're going to have to go on a waitlist for a long time, or buy addresses from the previous holder). However, most ISPs will require a higher tier connection if you want to bring your own IPs, so it's not something you can usually do on a residential connection.

The processes involved wouldn't really scale if normal people were going to do it either, but if it's something you care deeply about and are willing to spend the time on, it is possible.

As another poster said, you can get a tunnel from Hurricane Electric, or some other tunnel brokers, and that works too, although it's not as flexible --- HE tunnels are not geographically flexible, you pick where your tunnel is assigned, and those addresses will always be routed through that location. If you move far away, you'll likely want to setup a new tunnel in a new location for performance reasons.

> Is it possible for me, or worse, a normal person, to claim or request an ipv6 address that they can keep and use like a phone number?

Yes. You also have to get an ASN though, and an ISP which which will advertise both over BGP.

You don't strictly need an ASN in order to request address space, at least with ARIN. It's possible to have your own IPs, and arrange for someone else to announce them on your behalf, or use them on your local network without routing them globally.

(If you qualify for one, there's little downside to requesting it at the same time as your IPs, though)

> I have to admit, there is a learning curve. But I want to encourage everybody involved in configuring computers to learn.

This is probably most of it.

My gripe is that there is essentially no realistic end to ipv4 in sight. So we as an industry carry the debt of securing, managing and troubleshooting parallel v4 and v6 networks for decades.

If ipv4 had an EOL it'd make the transition so much better

We have reached the point where it is feasible to run all new networks on IPv6 and treat IPv4 as legacy protocol on the edges and special devices. NAT64 works well enough for most IPv4 access. IPv6 network greatly simplifies networking.

IPv4 will never go away, but will be smaller part of the Internet.

It will probably be 20-30 years before it goes away. But I think there will be a point where service providers that drop v4 support in their networks. At that point clients that need v4 connectivity can use 4-in-6 tunneling/VPNs.

It will absolutely hang around in small private networks for 50 years (there's still some token ring networks out there)

Nobody is in a position to EOL v4. We'd need a planetary government for that, and we don't have one. It would be nice, but we have to work with what we've got and not what we wish we had.

I run my desktop with no v4, so it's clearly possible to push handling for v4 out of your network. You could outsource it to somebody else even, for example by using one of the DNS servers listed on https://nat64.net/.

We can EOL things insecure ciphers and old operating systems without much issue without a planetary government.

The migration strategy for ipv4->ipv6 was just so horribly conceived that we'll be running both in parallel for decades.

TBH I think it would have been better if ipv6 was named something else entirely. Running TCP and UDP in parallel doesn't raise any flags, but running two versions of the same protocol in parallel is strange.

Can we? People continue to use both even after newer versions are released.

I don't think it was horribly conceived. I think it's close to the best we can do given the constraints we're working under. These constraints include the fact that there are millions of networks being run by millions of people and nobody is in a position to force all of these people to stop using v4.

IPv4 will have a slow lingering death. We'll reach a steady state where everyone's running dual stack or IPv6 behind a v4 proxy/CG-NAT. Then as V4-only traffic drops content networks/application providers will start to drop support.

That will drop the quality of the v4 internet, things will break and be slow to be fixed because who cares about the <10% v4 only traffic?

Stuff on the Internet breaks if I enable IPv6 on my Google Fiber router (been that way since I first got Fiber years ago—though I think Amazon works with it enabled now, which it didn’t before).

My T-Mobile connection issues an IPv6 address but fails online “is my IPv6 working?” tests.

I enjoy it on my private networks but simply can’t rely on it on the Internet yet.

I don't hate IPv6, but I am putting off switching my network to it for as long as I can get away with.

There's nothing I do that IPv6 makes better, and switching to it is a very large and painful task, so delaying that switch until it's required doesn't seem unreasonable.

You don’t have to switch your network to it, you just have to enable it. The system to decide between IPv4 and IPv6 works pretty well. I can’t tell if accessing HN over IPv6 cause doesn’t matter.

I've been looking into keeping my network IPv4 in an IPv6 world, and it looks like there are a lot of sharp corners and kinks that make that problematic.

In any case, considerations like that are part of why I'm putting off any serious effort or decisions until it's required.

The reason it's problematic is the same reason we need a new protocol in the first place: because the old one isn't enough.

You've spent longer talking about not deploying v6 than you would have done deploying it. I said this before, but I suggest you sit down and turn v6 on for your network -- and *just* that, don't start gaming out how to disable v4 or deal with devices that don't support v6 or anything else, *just* do the basic enabling v6 on the network part. That way you'll see that you're seriously overthinking it.

But you won't listen to me, because http://habitatchronicles.com/2004/04/you-cant-tell-people-an...

> You've spent longer talking about not deploying v6 than you would have done deploying it.

I guarantee that I haven't.

> I suggest you sit down and turn v6 on for your network

I did this a long while ago. I apologize for giving the impression that I haven't. But actually using IPv6 in any serious way takes more than just turning it on. It requires reconfiguring a nontrivial number of machines/devices, figuring out how to accommodate the many machines/devices that aren't able to use IPv6, and so forth.

Now, I will admit that I'm still learning IPv6 stuff and as a result there are likely things that I'm overthinking. But responses like yours don't move that ball forward any. You're just scolding people for not being experts.

> I have been deploying IPv6 for more than ten years and it really improve many situations (beside larger addresses).

for most people, it is transparent and doesn't improve anything... ipv6 could be disabled on their router and everything would be the same (I actually used to disable ipv6 at router level to avoid inadvertently leaking data on ipv6)

We spent a significant amount of effort designing v6's deployment strategy to make sure this would be the case -- that it could be deployed without disrupting existing network setups. It's supposed to work like this.

Don't twist that effort into a reason to not deploy v6.

IPv6 is after than v4. If you're running v4, you're probably running NAT44, that adds latency as the NAT box has to do a table lookup and rewrite the header. V6 it just passes the packet through.

Welcome to 2001, HN!

Finally.

IPv6 is still pretty useless to most people... Actually for me it complicates my firewall rules and don't bring any benefits (yeah down-vote me and don't reply ...)

I'll downvote you AND I'll reply. It complicates firewall rules? How about pass everything out, keeping state, and block everything in, for all of your fragile devices that can't help but run services you can't turn off? There. Your IPv6 firewalling is done. Is that complicated?

You can't see any benefits? Ok. So what does that have to do with HN being available over IPv6?

Because you can access a website on both ipv4 and IPv6 doesn't really make IPv6 all that useful because you could disable it and still be able to access the same resource using ipv4...

>IPv6 is still pretty useless to most people

My, the luxury of not being put under a CGNAT.

I don't understand what you mean by complicating firewall rules,except maybe that you now need to use IPv6 addresses instead of IPv4 addresses in some of the rules. It's not like NAT without a firewall gave any security in 2024.

there is no nat w/o a "firewall" and yes, it will be more secure

> there is no nat w/o a "firewall"

Actually, there is! People normally don't notice because NAT is usually co-located with a stateful firewall (since both need connection tracking to work, unless it's the rarer 1:1 NAT). But you can run NAT with firewall disabled, and in that case, it's possible in some cases for a device on the outside to access a device on the inside.

For instance, suppose a NAT router with 192.168.0.x/24 on the inside, and 192.0.2.1/24 on the outside. A malicious device at 192.0.2.2, on the same level 2 network as the router, wants to attack a host inside the NAT. The malicious device can send a packet with IPv4 destination address 192.168.0.x and the Ethernet destination address of the 192.0.2.1 router; if that router has its stateful firewall disabled, it will accept the packet and route it to the target device.

That is: what "protects" devices on a NAT without a firewall is not the NAT, but the use of non-globally-routeable addresses within the NAT, since a packet from the outside won't find a route to your NAT router; but if someone manages to route the packet to your NAT router anyway, it'll be accepted unless a firewall rule blocks it.

(If you want non-globally-routeable IPv6 addresses, you can use ULA addresses, which have similar properties to the IPv4 private addresses.)

true, un-statefull nat's exist but their usefullness is limited

The post you replied to was talking about stateful NAT. Stateful NAT doesn't firewall either. If you do what they described, you'll be able to connect in just fine unless there's a separate firewall blocking it.

A perfectly reasonable NAT implementation will allocate a router TCP port for an outgoing connection from a private IP, and will send ANY traffic that reaches this port to that private IP.

So, if I send traffic from 192.168.0.78:19990 to 1.1.1.1:443, the NAT may allocate TCP/29099 for this connection and forward traffic from its public IP, 3.56.54.90.

Then, if an attacker sends a SYN packet to 3.56.78.90:29099, the router will forward that packet to 192.168.0.78:19990. The machine may or may not accept that connection, but the attacker has reached it.

Now, many NAT implementions also do firewall-style tracking, and would not accept this packet unless it came from 1.1.1.1:443. But that is not required for NAT to work, and it requires extra memory per connection (storing the destination IP/port as well as the local IP/port), so I'd bet real devices exist that do this.

Actually, unless you disable all application layer gateways in your NAT, your IPv4 firewall can be bypassed quite easily. I don't know of any IPv4 NAT implementations where the ALG don't override the firewall (because that's the point of them).

If you configure NAT+firewall you're going to be somewhat resistant to configuration mistakes, but you can do the same thing on IPv6 if you really want to. However, for most consumer devices, all you get is "NAT instead if a firewall WITH NAT bypass methods so you can still use SIP and FTP".

More rules equals more complexity....

Yeah, sure: managing both IPv4 and IPv6 on the same network is painful. Thankfully you can disable IPv4 locally and set up NAT64 on the router: most people won't even notice the change.

"Pretty useless" is nonsense; Google works on IPv6, and 41% of Google's users access it via IPv6 [1]. "Most people" is also not true: most internet users use Google [2] (those not accessing it via IPv6 probably can't).

[1] https://www.google.com/intl/en/ipv6/statistics.html

[2] https://www.statista.com/statistics/216573/worldwide-market-...

Because you can access a website on both ipv4 and IPv6 doesn't really make IPv6 all that useful because you could disable it and still be able to access the same resource using ipv4...

By that logic, you can disable IPv4 and still access the site via IPv6.

IPv4 is useless.

Also, running dual-stacked servers I can confirm, all scans come via IPv4, so not only it is useless, it’s actually less secure to use it.

By that measure, port 22 is useless because you can change it....

How about all of the people who wouldn't be able to access the Internet because their country doesn't have enough v4 address. Or who's internet connection is better/faster because they're no longer behind a CG-NAT. (Think mobile carriers, developing countries, China, India, etc)

Reply on news.ycombinator.com