Tell HN: Hacker News now supports IPv6

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.

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...

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)

However, that only works with a /64 prefix

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

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.

There probably is a way to ask my ISP for a larger block, but I think it would be nice to be able to subnet a /64 regardless.

CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn't really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.

You can still use a shorter hash of the Mac address.

Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

Collisions are just as likely with the 48 bits as they are with the last 24 bits, as some OUI vendors reuse mac addresses.

Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.

Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

You can do that, sure. But it's more complex and slower.

It would rather be an ICMPv6 neighbor discovery packet or something like that, IPv6 doesn't use ARP.

On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested "Prefix Delegation" in which case they'd give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.

Some do give you one but in the most incorrect way possible. When I had fibre through Orange France, they properly allocated a /56 to my connection, but the ISP provided router only routed the first /64 from the block. The UI even proudly displayed the full /56 in all of its glory followed by a "xx/64 usable".

Oh and I ended up disabling IPv6 altogether as their router would crap itself with a modest amount of IPv6 traffic. Pulling ~10Mbps of IPv6 would completely DoS the router, as it would not even go as far as answering to ARP. Some quality hardware for sure.

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.

Not if you want SLAAC to work in each LAN. Basically in IPv6 each LAN is supposed to have a /64, that's the real minimum allocation by design. Per the official recommendations, ISPs are supposed to give every individual customer at a minimum a /56.

Ah, right. That leaves a custom dhcpv6 pools config for you...

This is the same as if you get a /24 from your ISP, but the ISP has the .1 address on their router. In this case, you can't (easily) subnet the v4 range either, since the ISP router expects to be able to arp for all the 254 ips, meaning you have to resort to trickery in order to make subnetting almost work.

Same goes for ipv6. If you get one single net (and a 'small' one at that), you once again have to resort to trickery to subnet at your end.

Preferably in both cases, you would get a small (/31 for v4, /127 for v6) transport net that goes to the ISP router or your first fw device, then the ISP routes the real net /24 (or whatever size you can get from it on v6) behind your IP on the /31,/127 so that your first device can split this in any way you prefer.

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.

Doesn't AWS currently hand out /128?

If you create a v6 VPC you can choose /44-/60. Subnets can be between /44-/64.

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.

They are fully compliant, SLAAC is part of the standard whereas DHCPv6 is an optional extra.

DHCPv6 also does not work without RA. DHCPv6 just assigns an address, a routable prefix, dns servers etc, it does not assign a subnet or any routes, you need route advertisements for that.

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

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.

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 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)

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.

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

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.

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.

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

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

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

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".

>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...

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'm sure people said exactly this about IPv4 back in the days.

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).

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.

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.

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

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%.

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?

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.

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 :)

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

We never learn

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)

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.

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.

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...

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/

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.

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.

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.

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/.

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.

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.

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.

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!

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).

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

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...

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.

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.

My local devices end up with new ipv6 addresses daily.

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.

You can disable IPv6 privacy extensions. The exact process depends on the operating system you use.

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.

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.

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 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.

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 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

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" ?

Solved you say? So how do I set up DNS for LAN hosts that under IPv4 would have static private addresses?

Under IPv6, you run into problems long before DNS - trying to assign static addresses as DHCPv6 is an afterthought, also whole setup has to be robust somehow when the whole network prefix changes.

Sounds like a good use for Multicast DNS?

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.

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.

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.

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.

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'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.

Which is?

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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)

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.

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?

You can determine that by looking at the value.

IPv4: 123.123.123.123

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

Oh yeah. DUH!

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...

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

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.

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.

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.

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.

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.

$10M USD

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

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.

Offtopic:

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

Finally someone who understands the basics.

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

$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.

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.

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).

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.

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.

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.

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-...

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?

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.

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.

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)

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.

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-...

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

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.

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.

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 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

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".

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.)

More rules equals more complexity....

"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.

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.

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.

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?

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. ¯\_(ツ)_/¯

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.

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

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

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

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]/

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.

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

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... >:)

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

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.

Finally.

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

Welcome to 2001, HN!

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!

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.

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