IPv6 xmas display uses 75 Internet's worth of addresses | Hacker News Reader

IPv6 xmas display uses 75 Internet's worth of addresses

hackaday.com

337 pointsfanf2123 comments

Open articleView on HN

> Since the led wall was being flooded with inappropriate content we had to implement a whitelist system...

That was probably inevitable.

The last scrolling LED message I read was "Uncaught type error: Undefined is not a function."

Is one of you out there trying to fuzz this poor tree? :)

For fun, this is sort of a parody of ipv4 exhaustion counters:

https://samsclass.info/ipv6/exhaustion.htm

I have two /29 of ipv6 and at current consumption rates they should last until the end of human civilization.

For reference of size, a /32 of ipv6 is what any ISP can get from Arin or ripe just for asking.

https://samsclass.info/ipv6/exhaustion-2016.htm

Who doesn't like fitting a power law!

Part of me feels like this will not be enough if they continue to give huge blocks away. We will find trivial ways to use them. ipv8 or ipv16 or ipv1024 will come in our life times.

Sadly at the same time in many countries IPv6 is next to non-existent[1]. I follow closely when China will adapt it, since was announced long time ago, but seems no progress since.

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

The three major ISPs in China just deployed IPv6 in most cities, though IPv6 based routing and DNS is still suboptimal. I don't know how Google generate the ipv6 statistics, but in the case of China it may not be very accurate. Most Google services are blocked there.

I live there and I don't see a change. Other, non-Google counters are also not very optimistic.

EDIT: My bad, I just checked today and there are positive changes - all my connections are now IPv6, mobile and fixed line. The IPv6 speed as opposing IPv4 one is very low though...

which isp do you have? a small local one or one of the three big ones (telecom, unicom or china mobile)?

China Telecom.

The statistics are generated based on which protocol is used to access Google, so if Google is blocked it won't show up here.

That chart seems very hopeful to me. Constant linear growth. I expect there will be a tipping point where enough people have it that some smaller sites go v6 only to cut costs and the rest of ISPs are forced to adopt it. My vps provider gives you a $2/month discount if you don't take a v4 address.

Zooming in: Cubic, not linear, right? (No snark, just curious if I got it right)

The growth was superlinear until 2018: https://hub.mybinder.org/user/ipython-ipython-in-depth-gq7r1...

Another interesting things I noticed - pretty consistent ipv6 usage spikes on weekends.

All mobile networks NAT v4 and prefer v6. Many residential networks have v6.

Corporate filtered internet is typically v4-egress.

A thought: you could address all the bits in a 1TB hard drive with 8e+12 IPv6 addresses. Meaning you could do this with up to 4.25e+25 1TB hard drives.

Someone think of something cool to do with that.

Size comparison: https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self...

Twitch builds a TIFF image?

A partition table and file system first, please.

Makes me wonder if this could be used as an obfuscated comms channel? (I'm sure there's a term covering it, steganography doesn't quite describe it). If you owned a bunch of ipv6 addresses on multiple ISPs, you could use the timing of pings from these addresses as a comms protocol. You could even rotate IP addresses and use the modulus of the address to add a layer of obfuscation.

Quiet hosts with an unpublished v6 address are AFAIK impossible to discover in a better-than-linear-scan fashion from other networks (e.g. The Internet).

No different than obfuscating in higher level abstractions on a single IP as has been done forever. In either case you are getting a block of identifiers which have guidelines on how they should be used but no enforcement by design of the protocols.

As an example things like port knocking can be carelessly translated into IP knocking. Doesn't make it any sneakier though, just less header.

What would be grandma-proof equivalent of the implicit firewall provided by ipv4 NAT?

The Right Way would be to make informed decisions per-port and per-protocol, but that's a nightmare to set up, and to maintain.

NAT is not an 'implicit firewall'. Firewalls do packet filtering, NAT mangles routing. These are different things.

If you're trying to solve the problems of "How do we stop anyone on the internet sending packets to grandma's open ports?", then the answer is a packet filter. Thankfully, must sane consumer routers come with these.

NAT overloading private IPs onto a single IP (what 99% of consumer routers are doing) is an implicit firewall. Without additional protocols like UPNP or manual configuration of port forwarding, nothing behind this style NAT can receive unsolicited traffic.

“Mangling routing” to a single source IP requires state tracking of outbound sessions to know where to send inbound traffic. No outbound traffic, no session, no inbound traffic.

If NAT is an implicit firewall, then so is an unplugged network cable. I guess it's technically true, but isn't a particularly meaningful assertion - you might as well say that NAT is also 'not a donkey'. Again, technically true, but doesn't really help.

Firewalls are packet filters. Confusing routing and packet filtering doesn't help anybody solve any problems.

We're talking (I think) about how to mitigate threats from the public internet by dropping unwanted traffic with IPv6. The answer is a firewall (as it is with IPv4).

I can hook grandma up with a $30 chinese NAT box, disable UPNP and she's mostly safe from all sorts of port knocking attempts - while still having internet that seems to work great for her.

What would be the ipv6 equivalent? You can call it a donkey all you want.

The equivalent is buying her a $30 Chinese router that supports IPv6 and comes with a firewall enabled by default (or is configurable).

Exactly. Rip out all of that logic that maintains the address translation table and performs address mangling and you have a simple stateful firewall that's obviously less complex. It's difficult to see how ripping out the address translation could be more exploitable or costly to maintain. Ideally, we'd start with things written from the beginning to be stateful firewalls, but if I worked for a home/small office router ventor, my first course of action would be to just ripp out that potentially buggy address translation part of our existing NAT implementation.

Great! Which one is that? Do I need to buy it and perform some extensive testing first to figure that out? Looking forward to it!

Pretty much all of them?

My expectation is far far lower. And those that are might not still be decent after an upgrade (and you won't know if the hardware or software you buy will be of another revision).

Hardware that happens to be popular are often updated to a cheaper variant where the manufacturer rides on the fame and good reviews of the original version.

So you can't even do the research once and expect it to hold for future purchases/replacements.

Well, instead having "expectations", how about just checking it yourself before spreading FUD?

No amount of FUD comes close to the reality when it comes to home routers.

usrusr explained it nicely. It will likely take years before anyone will realize that the firewall doesn't work at all. Whereas a similarly broken NAT router will be declared DOA.

The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you. A bridge is not NAT with some features switched off, it's an entirely different topology. A v6 router without the firewall will still be a router. When setting up, people just want "the internet" to appear in their browser, that's their definition of done and NAT made it extremely unlikely to get there with universally open ports.

> The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you.

Broken NAT:

  iptables -t nat -A POSTROUTING -o outside0 -j MASQUERADE
  iptables -P FORWARD ACCEPT

Google works fine, but when somebody sends the external interface of my router a packet with destination address 192.168.1.42 (as can often be done from any compromised router on the same cable segment), it gets forwarded to 192.168.1.42 on the internal network.

NAT is not a firewall.

Hook grandma up with a $30 chinese firewall box, and disable UPNP? Plug modem into WAN, computer into LAN, turn it on, done.

True, it will be called a "router" in consumer speak, but all consumer IPv6 routers should actually be firewalls.

A connection-based NAT does filter! Any source not in the database gets the packet discarded.

And this is the confusion most people have!

NAT isn't doing that filtering, the stateful firewall is.. Every NAT device sold in a very long time has both features..

Some early DSL modems for example had only NAT, and they were horribly insecure.

NAT is not a firewall, and provides near zero security. And, in combination with a stateful firewall, it provides exactly zero additional security.

But how so? If my public address gets a random packet and there are 5 devices on the lan side, which local address did those devices send unsolicited inbound traffic to? Where's the insecure part?

Yes, because there is no firewall state. There is both firewall and NAT state for every established connection.

Exactly. Remove the firewall state, and you're wide open for all the NAT'd ports. And if someone thinks they don't have any NAT ports, they would be wrong. You likely have 10's or 100's ports NATd for every device activity being used on your network.

To the various remote management ports listening on the DSL modem itself. Between RCE vulnerabilities, accidentally unauthenticated management features or even just upnp listening on the WAN port, there are infinite means for owning the network behind the device.

But that's more of a general problem that still happens on modern devices, even with ipv6. ISP wants some port open on the device for remote management but is so incompetent that it's actually reachable worldwide.

Yes. I was just responding to the claim that with IPv4, thanks to NAT a malicious packet would not be able to be routed anywhere unsafe.

A NAT router without any kind of firewall functionality is incredibly unsafe too so even the cheapest ones have some of it these days.

Which follows that the cheapest IPv6 routers would also have a firewall and thus would not be inherently worse at protecting the internal network than a v4 router doing NAT would.

If one of those 5 tries to connect e.g. to a remote windows file server .. you now have an open port on your public IP which will accept packets from any IP on the internet and will forward them to the windows file share service on your desktop.

Add a stateful firewall with connection tracking, and that port is only open to the 1 server you tried to connect to.

Yes that's true, but not a problem for TCP since the attacker had to know the outgoing port from the ephemeral port range your PC or router picked, and then had to take over the running TCP session by additionally knowing the connections state (sequence number etc). For UDP you indeed have higher chances of talking to that device in an unsolicited manner, and this has been exploited by games and later Skype in the past. So yes, indeed more insecure, I stand corrected. I'm still more worried for actual exploits or security holes even in modern devices that can do proper firewalling the ISPs provide due to incompetence or laziness. Like the TR069 port being open on many devices two years ago.

Yes, the modem/router is likely buggy as hell, most "consumer grade" CPEs are. The best defence for that IMO is to remove as much code as possible - like the unnecessary for IPv6 NAT stack..

If your public address gets a random packet then the packet is addressed to your router, not one of your local devices. This is insecure if the router is providing some insecure service on that port, but otherwise it's irrelevant to this discussion.

The problem comes when your router receives a packet addressed to one of your local devices. Many people in this thread believe that if the router is NATing outbound connections, it'll drop this inbound packet, but that's not what happens -- the packet will actually be routed to whichever local device it was addressed to, just like any other packet would be.

This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).

(You can configure a NAT to do things to inbound connections using port forwarding rules and/or a DMZ, but those rules only apply to specific inbound connections. Connections not covered by those rules are treated as normal, and "as normal" for a router means normal routing.)

NAT isn't a firewall, because it doesn't drop connections. All it does is rewrite addresses on connections, not decide which connections can and can't be made.

> This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).

Absolutely. It's trivial to demonstrate how utterly useless a router configured with NAT, with routing, but without a firewall is. (Useless in the context of a home CPE device for the average home internet subscriber..)

As a side note, yes, packets arriving towards your router with a destination address on your LAN will be forwarded by the router piece of your router.. the firewall piece would prevent this. This is independent of the use of/absence of NAT though..

You can't just separate it out like that. It's impossible to do a connection-based NAT without state.

But it's not trying to drop anything. You can set a default device to throw all incoming connections at.

And with a pure NAT you can't set any rules about what to allow or drop. It only acts like a firewall from one very narrow angle.

This seems to be agreeing with me and many of the others? A stateful firewall is a useful thing on its own, but it's also a fundamental requirement for modern NAT implementations.

NAT on the other hand is not a fundamental requirement for a firewall.

NAT bolts onto a firewall, and it's the firewall that provides the security. Remove NAT, and you haven't lost anything in terms of security.

I'm saying that such a NAT can exist by itself without a true firewall.

A stateful firewall isn't a fundamental requirement for NAT though, even modern NAT ("or actually PAT", as other posters seem to like saying...). State tracking is certainly a requirement, but tracking state is separate from firewalling based on that state.

This is why firewalling is separate from NAT, and why NAT isn't a firewall. Yes, it's true that both NATing and firewalling rely on tracking state, and typically both NAT and firewalling are implemented together in the same software and hardware, but they're two separate behaviors and you can do one without doing the other.

Nobody is advocating replacing cheap NAT home routers with unprotected routers. They're all advocating replacing cheap NAT home routers with cheap stateful firewall home routers.

What the GP is trying to tell you is that you're conflating sateful filtering with NAT. If you rip the address translation part out of a NAT implementation, you get a stateful firewall. You're probably better off with a purpose-designed stateful firewall, but ripping the NAT out of NAT works and is an obvious reduction in complexity.

Insisting that you lose packet filtering if you get rid of NAT is a straw man argument. Nobody is arguing for that. They just want to remove the address mangling portion of the cheap router while keeping the packet filtering.

No it's not. Case in point, I've had a misconfigured router provided by an ISP with proper NAT but bad firewalling, and hacking on routes allowed me to jump into neighbors LANs on the same ISP. Crazy.

This is true, and it's the very minor security benefit of NAT. However, without the stateful firewall in addition, you're wide open to attack.

Have a windows PC? Did you try access a network share that exists outside your network? Well, now the SMB port is open. Anyone on the internet can reach it. Hopefully your desktop has a stateful firewall to mitigate the hole in your router....

There's going to be hundreds of other examples.

Not really, NAT will keep track of destination address as well so unless the network share outside the network is also the address of an adversary, the SMB port isn't open to the internet.

NAT doesn't do this on its own. It would be a duplicate implementation of the stateful firewall, so NAT leaves this piece to the firewall.

NAT is nothing more than a lookup table of router IP+Port and internal IP+Port pairs.

(Well, PAT style NAT anyway... But that's what everyone here is talking about...)

Your thinking of the firewall that's built into most consumer routers. The exact technicalities of NAT (PAT actually) are not super well defined, and many implementations will not track the destination address.

I don't think that remote network share access is very common among home Windows users, but Skype is. The last time that I pointed nmap at a PC with Skype on a conversation, the output of open ports was more than a screenful. Skype listens on literally tens of ports.

Granted, this was a while ago.

It's been a while since I used a windows machine that wasn't connected to a domain / managed by a IT dept... But isn't windows file sharing enabled by default on home editions? And from memory, no authentication is required to interact with the service - it's only after you connect, obtain a list of shares, and attempt to open a share that authentication becomes required - leaving plenty of room for bugs to be exploited.

At the end of the day, opening ports, any ports, is "dangerous".. A stateful firewall prevents much of the danger introduced by ports opened via NAT.

Windows ships with an enabled-by-default stateful firewall which rejects any connections from sources not on the local subnet.

Right, but if someone thinks NAT on its own is protecting them... I'll bet they turned that local firewall off too the moment it got in the way of $thing they needed to do ;)

> nothing behind this style NAT can receive unsolicited traffic

This isn't really 100% true though. Since IPv4 NAT was never standardized, many many variations exist in the wild and some can be exploited to send unsolicited traffic inside the network defeating the implicit "firewall" aspect of NAT.

NAT translates IPs. Firewalls allow or block traffic based on a policy. In some configurations (static NAT, port forwarding, etc. etc.), there's no firewall aspect to NAT at all. In others (PAT, what this discussion is mostly about), there's often an implicit firewall, but different implementations have widely variable behavior, and it basically should not be depended on as a firewall.

If you want to deny inbound unsolicited traffic, then you need a firewall.

Most consumer grade firewalls that support IPv6 have easy to configure options for this.

My router helpfully has it hardcoded on block everything :/

The "implicit firewall by IPv4 NAT" is functionally the same as:

Outbound allow Deny all

In any stateful firewall implementation. The only difference from IPv4 is the ruleset doesn't have the NAT statement.

100% agree. A simple stateful firewall is more simple than a NAT box, and all else being equal, is likely less exploitable/buggy.

Some will argue about what the exact firewall rules should be, but we can have that argument after we all agree to replace NAT with sateful firewalls.

Definitely.

I suppose this was meant to say "outbound allow all / (inbound) deny all".

Nitpick: please make sure ICMPv6 is allowed inbound though, else you'll get PMTU issues among other things.

This is true of IPv4 ICMP as well. Same PMTU issues, but many IPv4 implementations fallback to allowing in-path packet fragmentation by the routers (which IPv6 discontinued), which is less visible breakage but still inefficient/problematic.

It's also slightly more complicated than "outbound allow, inbound deny" because you want to accept reply packets to the outbound ones, using something like the iptables "-m state --state related,established" match.

You need basically the exact same stateful firewall you already need with IPv4 even with NAT, except that with IPv6 you need to allow ICMP as well otherwise path MTU can break.

On the in chain - allow ICMP, allow established/related, block otherwise. Open up any additional ports as needed, just the same as you used to do with port forwarding before.

All routers, even crappy consumer ones should have a basic stateful firewall on by default. Hopefully with sane default settings.

/r/place with ICMP as user interface/API, I love it

how about a new message protocol: IP over ping. 255 addresses, each ping sends one byte. bytes are ordered by the pings timestamp

You mean ICMP Echo.

right, "IP over ICMP Echo" will be the formal title for the RFC.

"IP over ping" is the street name that everyone is going to call it, or IPing for short.

also: TCPing and UDPing will replace TCP/IP and UDP/IP respectively.

Already exists

https://en.m.wikipedia.org/wiki/ICMP_tunnel

that's different. that puts data into the ICMP Echo payload.

IPing packets contain no data at all, but the data byte is encoded in the destination address

I remember the original IP v6 xmas tree. The one you see when you visit the site but get redirected soon.

It is truly something that got me involved and learning networking to say the least and what a fun way to put it accross.

This one is like 10 times more dank.

It is nice because it's a xmas display, but it's nothing magic. IPv6 lets you do many things very simply, and it can get very messy too (which is fun by itself!)

They got a /48, and they got some inspiration. You too can get a /48 easily if you want to play! Even if you don't get a /48, you can do some messy play very easily.

My personal experience being messy: when I had to handle multiple containers on one actual computer, I had enough IPv4 addresses (like A.B.C.D) to give one per container, but just a single regular W:X:Y:Z/64 (the suggested minimum default for IPv6, like with SLAAC, while a /56 is often better even for a home network)

The provider wanted some insane amount of money for a decent IPv6 allocation while usually it's the opposite, and IPv4 is expansive but IPv6 is mostly free. I didn't want to use tunnelbroker to keep the latency low.

So I simply assigned W:X:Y:Z:A:B:C:D to each container -- because, why not? Yes it's wasteful, but it's easy to figure out which is which!

IPv6 make many creative things possible and simpler than what the equivalent IPv4 solution would be, simply because of space constraints.

After reading https://blog.donatas.net/blog/2018/12/14/geodns-ipv6-failove..., among my new year resolutions is setting up a CDN using IPv6. It's mostly to play with BGP.

> So I simply assigned W:X:Y:Z:A:B:C:D to each container -- because, why not? Yes it's wasteful, but it's easy to figure out which is which!

It makes me curious. Did you apply any service-discovery mechanism in your IPv6-based container cluster? I wonder if IPv6 makes orchestration easier, tougher, or actually things just work transparently.

No, I didn't do anything that fancy even if it's what I really wanted in the first place :-)

Full story: initially I wanted to do SLAAC with different subnets for the different physical computers.

To do that and use the MAC address of the containers in a "standard" way, I would have needed a larger subnet that what the provider even had for sale - but then everything would indeed have been much easier and automatic.

In case it's not clear, imagine having W:X:Y::/48 like the xmas tree example, then using Z to identify which physical computer the container is on: then A:B:C:D are automatically derived from the hardware address of the (here virtual) interface.

It's also very handy if you have multiple networks - say a wired and wireless setup: use a different value for each network on each site say Z=1 for your wired netword, Z=2 for your wireless, etc.

Then you can automatically populate AAAA records like computername.connection.site.yourdomain.com. Why is it cool? Then if you need to check connectivity or push updates or whatever, you can ping6 ceolaptop.wifi.nycoffice.yourdomain.com- but don't worry, that IPv6 address will not be leaked if you are using the privacy additions (lft=0 aka deprecation): this laptop will use a "throwaway" IPv6 access so it can't be tracked (well, at least the mac address part, but good luck finding the needle in a haystack!)

See https://en.wikipedia.org/wiki/IPv6_address#Stateless_address... : A 64-bit interface identifier is most commonly derived from its 48-bit MAC address. A MAC address 00-0C-29-0C-47-D5 is turned into a 64-bit EUI-64 by inserting FF-FE in the middle: 00-0C-29-FF-FE-0C-47-D5. When this EUI-64 is used to form an IPv6 address it is modified:[1] the meaning of the Universal/Local bit (the 7th most significant bit of the EUI-64, starting from 1) is inverted, so that a 1 now means Universal. To create an IPv6 address with the network prefix 2001:db8:1:2::/64 it yields the address 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the Universal/Local bit, the second-least-significant bit of the underlined quartet, inverted to 1 in this case because the MAC address is universally unique).

I'm not very experienced when it comes to such low-level networking, but I'm curious as to how they claimed all those contiguous addresses. Is there some fundamental difference between IPv4 and IPv6 that let's you do this?

Not as such, it's just that v4 is so small that most ISPs don't bother to give routed prefixes -- or rather they can't, since there aren't enough addresses available to do so. In v6 it's typical to get something like a /56 from your ISP, which is 2^(128-56) = 2^72 addresses.

(v6 also has a protocol, DHCPv6-PD, to manage prefix delegations automatically, whereas v4 requires manual config or some custom mechanism.)

You could argue that the difference between 2^32 and 2^128 is big enough to be considered a fundamental difference.

(Also: "lets".)

Anyone have details on how they did the networking part of this?

I can think of several approaches (all using a single PC for all the IPv6 addresses), but curious which they chose.

This is a PDF presentation from how the original tree worked in 2016 http://mum.mikrotik.com/presentations/NL16/presentation_3994...

I imagine it works the same way now just with the added x y coordinates.

You sure that’s the right link? The presentation slides link on that page didn’t seem related.

Edit: n/m, watching the video made more sense. That said, it wasn’t simply “adding the X Y coordinates”, the Christmas tree example didn’t use IPv6 or Ping, but I’m sure the process was likely similar.

tl;dr They use a Microtik firewall which uses an rsyslog forwarder with an Arduino to control the Christmas lights.

And people say that Moore’s Law has broken down! Sure, processor speeds aren’t increasing as fast, but that’s more than made up for by the incredibly rapid increase in the number of Internet addresses per device.

What does the density of transistors in a circuit have to do with switching to larger addressed v6 which was standardized and first implemented in the late 90s?

Ipv6: making it trivially easy for Facebook and Google to track individual devices!

(I certainly understand the problems with ipv4, but ipv6 reveals far too much information in it's current state).

RFC4941 begs to differ.

https://tools.ietf.org/html/rfc4941

Think a little broader. The IPv6 Privacy Extensions just shield your mac address unless I've missed something.

Let's say I'm a transit provider [like Google]. Right now, I see TLS traffic from your public IPv4 address to another public IPv4 address. I have no idea how many devices are behind those public IP addresses. I can maybe combine a few assumptions with my browser-based tracking, but it's difficult to identify you in apps I don't have control over.

Switch to IPv6, now I know exactly how many devices behind your firewall are talking and how many devices you're talking to.

Even better, I can combine this with a browser-based tracker and I can see what you're doing in apps I don't control. I first identify you with the browser and what IPv6 address you're using. Then as you use other apps that I can't spy on, I just have to look for your IPv6 address in my transit traffic to figure out what you're doing.

A solution could be a Firefox browser extension that allocates a huge number of v6 addresses to your computer dynamically from your LAN /64 or /56 and creates fake garbage google usage data, so that google can never build a profile on you based on v6 address (if you are this paranoid).

Or... just stop using google and use uBlock Origin to block all Google domains.

So...you think Facebook and Google don't already track individual devices, even with IPv4?

Where did you read that? The GP comment talks about something completely different.

Yeah, except for the fact that IPv6 privacy extensions have only been around for more than a decade...

Your IP address is the dumbest way to track someone. You can uniquely identify a browser easily and keep tracking after they switch networks.

Last 64 bits in ipv6 address is your MAC address.

Ipv4 did not have this. Many users were allocated IPs temporarily from IP pool

So it was difficult to track inviduals devices as IP would change all time.

Please go ahead and Read RFC4941.

A MAC address is 6 bytes, so 48 bits

> ipv6 reveals far too much information in it's current state

What information does IPv6 reveal?

If we keep going in this direction we will quickly run out of adresses again.

Your concern is, um, addressed in the article.

It says you get up to 10^27 of them. While that’s a lot, it’s right back in the ballpark of usable v4 space.

No, it's not, it is many, many times larger than 'usable v4 space'. Like, if each of the hypothetical 10^27 displays was given a single IPv4 address we'd run out and still need to assign billions of billions of displays.

V4 is 2^32 or 10^11. You could fit an entire IPv4 with an entire IPv4 nested inside each one, throw them all away and repeat every day for 300 years.

Screw math. I'm still with the OP's darn rec'n'n, it's more truthy!

It's _massively_ bigger - (10^27)/(2^32) = 2*10^17. 17 orders of magnitude is not in the same ballpark (you could give every IPv4 address an entire IPv4 address space, and it'd _still_ be bigger (54 million times bigger)).

No, it’s not. My concern isn’t this particular implementation, it’s that implementations will keep using up larger and larger chunks of adressable space.

Thinking something is unlimited is the fastest way to find out that it is.

If you keep sipping from that water glass you will quickly empty the world’s oceans.

If this becomes more common, the IPv6 address space will be exhausted pretty quickly. There already was a proposal on encoding phone numbers in IPv6 addresses.

There are 2^128 available addresses in ipv6. Encoding phone numbers isn’t even remotely a problem.

Well, the proposal was controversial.

There was an article about this recently on the German news site Heise: https://heise.de/-4196981

Translation: https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...

The article has a note on that saying:

> If you think this use of addresses seems wasteful, you needn’t worry. There are around 3.4×1038 IPv6 addresses, enough for 10^27 such displays.

So even an intentionally wasteful project has plenty of headroom for quite a while yet!

By "this" I mean encoding information in the address in general, not this signage-thing. See my other reply in this thread.

Everybody seems to make a big fuzz about ipv6. Yet for some reason, it seems to be of no importance to my life at all.

I'm a fulltime native of the web and yet I don't even know if I have ipv6.

I just typed 'do i have ipv6' into Google and the first page I landed on says "0/10 You appear to be able to browse the IPv4 Internet only.".

I doubt I am missing out on anything. I'm sure I would have noticed.

I also make a living from the web, yet I don't even know if my websites support ipv6.

Let me type 'test website for ipv6' into Google and see what happens ...

...ok here we go:

"No AAAA record. This website is not ready for IPv6."

I get that for all my websites.

Again, I would be very surprised if that has any impact. Somebody would surely have told me that my websites don't work for them. They are constantly in the press and on social media. Some users would surely mention it if they had problems accessing them.

Why do I see all these pictures of hungry children in Africa? Don’t they understand they can just get food at the supermarket? That’s what I do.

IPv4 is not sustainable, we're already running out of IPv4 addresses.

Unfortunately, some ISPs only provide IPv4 support, so (almost) all websites have to support IPv4. And as all websites support IPv4 there is no insentive for ISPs to add IPv6 support. Repeat ad infinitum.

I would pay an extra $X per month for a handful of public, statically allocated ip addresses for the boxes in my house.

Ipv6 would make that easy for my isp, but they're still never going to do it.

You can always get a tunnel from one of the many tunnel brokers. Some are even free. I've used he.net back in the days before my ISP had native IPv6 support.

I'm still using my HE.net tunnel, and have been using it for more than 4 years. My ISP started BGP-advertising 2 IPv6 /32s 2 years ago... still no news. I fully expect that when they do deploy IPv6 to their customers (at this rate, it will be some time in the 2030s) that they'll only give you a single /64; they're that annoying.

Very excellent tunnel service too. I'm pretty sure it's gone down less than 8 times in that interval.

If you make a living of the webpages you might want to read up on the IPv6 adoption on mobile networks, as supporting it can greatly increase the network performance for your customers. Your websites will work, but for some clients the traffic might end up going on a little detour, slowing things down on an already slow network connection (relatively speaking).

I bet you already support IPv6, you just need to configure the relevant DNS records. If not, you might want to consider a change of host, as there's no good reasons for them to not support it today, and you're probably better off with someone else then.

A lot of mobile users don't have an IPv4 address on their phone. The magic of NAT64 is allowing IPv6 users to talk to your IPv4 sites just like the magic of NAT was the only thing keeping your IPv4 sites being reachable the last decade since we started to run out of addresses.

You may not need to know about it but it's already started to save your ass without you knowing.

Reply on news.ycombinator.com