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

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.

Miners need the least amount of permissions anyway.

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

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.

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.

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

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

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

IPv4: 123.123.123.123

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

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

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

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

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

I see:

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

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

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

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

Isn't that a pain in the butt?

The most common setup for this is that you have a static link-local address, and a static global address. And listening processes should listen to these static addresses.

Then you have a temporary global address, and outbound connections should use the youngest temporary global address (because temporary addresses don't disappear when they age out, they disappear when they age out AND no existing connection is still using them).

The net effect is that the address you leave in example.com's httpd logs is a temporary address that has no listening processes. And the address you use in dns, mdns, when connecting intentionally, etc is a static address.

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.

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?

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

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

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.

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

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

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

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

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.

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

That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).

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.

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.

* Sparse networks. 64 bits is too big to feasibly do a brute force scan on, which reduces how often servers get exploited by random network attacks. * SEND secures NDP by using those 64 bits for a public key

Reducing network sizes to 12 bits would destroy both advantages.

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.

   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.

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.

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

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.

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.

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

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)

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.

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)

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.

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

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

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

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.

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

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.

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

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.

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

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

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.

Weren't they supposed to allocate a /48? 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

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

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.

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!

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

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.

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.

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

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

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.

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

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.

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.

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?

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.

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.

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

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.

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

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.

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

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.

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

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

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

Awesome!

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

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)

Eg: Sometimes IPv6 is faster due to routing differences.

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.

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

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.

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

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.

???

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?

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.

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

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

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.

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.

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

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.

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

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

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.

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 new Godwin's Law, any discussion about IPv6 will inevitably lead to someone suggesting IPv4 with extra octets.

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.

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

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.

Seriously, I have yet to see a good tutorial how to herd IPv6 LAN with reliable local DNS, as is usual with IPv4. Everything is just handwaved away "nah, zero configuration". The reluctance to adopt it could stem from that.

Macs and iPhones have relied on mDNS for years. Windows supports it. Android supports it since 2022. Linux has avahi.

If people could look a little further than the tip of their nose, they’d realize how much easier it’ll be to explain to people to just type in alices-iphone.local instead of trying to find the IPv4 address first.