Hacker News Reader

> IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it.

No, it's not. It has been around, in production, for TWENTY YEARS. If you didn't learn about it when you were learning IPv4 you're either old and should already have enough experience to know that new things come up, or you should've listened when everyone told you that attending ITT wasn't a good idea.

"But MY company never deployed it!" Bad excuse. Your phone started using it years ago. If you're a network engineer and didn't realize that, nobody is going to feel bad for you.

Not intuitive? The same can be said about most technologies. Without real examples, this means little.

Can't phone a friend and give an IP address? I've literally never done this. We all use SMS, Messages, email, whatever, and anyone who does anything like run gaming servers knows about dynamic DNS services.

Come up with some better complaints, please.

> No, it's not.

Apparently it is if we are still having this conversation after "TWENTY YEARS".

Is there a particular reason that every aspect of your comment is toned with subversive rudeness and you made zero actual good points? Making snide comments about being "old" or how I "should've listened" and "no one is going to feel bad" really doesn't help anyone understand why IPv6 is all that great.

> Come up with some better complaints, please.

The author already listed several frustrations with the protocol. Feel free to read the article again if you'd like some examples.

Twenty years of poor adoption world-wide demonstrates its lack of easy integration. I don't need to argue this, you just did.

Also, mentioning dynamic DNS services at all in regards to trying to send an IP address to someone is yet another point to support why IPv6 is not an intuitive protocol to work with, even for something as simple as setting up a gaming server with a few friends.

> Twenty years of poor adoption world-wide demonstrates its lack of easy integration. I don't need to argue this, you just did.

This isn't down to the design of v6 though, it's down to two things: the design of v4, and human laziness.

v4 isn't forwards compatible with a larger address space, so there's no way to magically integrate a larger address space with existing v4 nodes. All of the possible ways to make cross-compatibility easier are already available in v6. Updating the internet's L3 protocol is simply a hard problem with no real shortcuts.

As for human laziness: v6 deployment didn't really start until 2013. Deployment was at 1% in 2013, and is at 30-35% today. People put it off until after the RIRs started running out of addresses to allocate, even at the cost of paying extra money to keep v4 working. This isn't a technology problem, it's a human problem.

> even for something as simple as setting up a gaming server with a few friends.

This isn't even possible in v4 for a lot of people today, due to v4 exhaustion. It's going to become less and less possible over time, as v4 exhaustion gets ever more acute. Even if we took at face value your claims that v6 is unintuitive (which I would disagree with), surely it's better to be able to set a gaming server up with v6 than to not be able to do it at all?

> dynamic DNS

The fact that IPv4 is reasonably usable by itself and IPv6 is not (it basically requires DNS) is a completely valid point against IPv6. Also, the joke about "it's always DNS" is there for a reason; depending on that makes it less resilient.

>Your phone started using it years ago.

But I hate my phone.

> "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind"

IMO ipv6 would have gotten far more adoption had they used a different assignment scheme:

* Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142

* New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly.

In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today.

Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now.

Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.

Then you are missing the chance to simplify things though.

In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network. Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough?

In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP. Compare this to the IPv4 case where each ISP will have hundreds of /24s. Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.

Indeed the routing tables can be simplified with ipv6. However I believe that the current solution is optimized too much for routing tables, and not at all for end-user usability.

You can modify my proposal to have multiple 16-bit prefixes to the 32-bit range syntax, and from that /80 range you give ASs depending on size a /104, /96, or /88, or something in between. That would still leave plenty of room for the ASs to distribute addresses to customers. Maybe customers could get /8s or such, with the option for bigger customers to get larger assignments. NAT on the router could be enabled by default, reserving the range for devices which explicitly request a publicly reachable address. Usually in most networks that number should be small.

End users do not need easier IP address unless they host something. even then one can use address compressed address and DNS.

The thing with IPv6 is it very different than IPv4, as such how we use it should not be compared with IPv4.

My ISP gives /64 for CPE and the internal routing is very easily setuped. My devices in the hotspot has different IPv6 address, VMs have different IP address. The communication between the devices happen locally without any NAT.

Every IPv4 address has its own IPv6 /48 automatically assigned to it. Forget getting more adoption, apparently it wasn't even enough to stop people from suggesting that v6 should've done something it already did!

Yes there are multiple ways that ipv4 can be translated into the ipv6 range. That's not what I'm suggesting here. I'm suggesting the existing ipv4 assignments to natively work in ipv6.

And we have that, don't we? Every assigned v4 address comes with a v6 /48 too. There's no translation involved with that.

What I indicated in my comment above is that I dont know which of the many existing ways to embed the v4 range into the v6 address space you are talking about. Can you please tell me so that we can discuss it?

Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.

I'm thinking of 6to4.

That would only work, at best, in 1 direction. If Alice has IPv6 and Bob has IPv4, Alice can send Bob a packet to either 1.2.3.4 or ::01:02:03:04, but if Alice's IPv6 number isn't in the IPv4 range (ex: ::10:11:12:13:14), then her IPv6 number won't have a corresponding IPv4 number that she can put in the IPv4 IP header (because the IPv4 header only allocates enough bytes to exactly fit 1 IPv4 header in the from field and 1 IPv4 header in the to field).

This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.

What I'm suggesting is both Alice and Bob speaking ipv6. ipv4 is only used for handing out assignments to ipv6 users. If most dual stack networks use the same assignments for ipv6 and ipv4, and ipv6 routing tables are directly copied from ipv4 routing tables, then Bob can talk to Alice if their ISPs support ipv6. It's a simple upgrade instead of having to get totally separate assignments.

What happens when future people want to use other addresses outside those rules? Tons of software will have been written only ever seeing the limited address range and will have bugs for more general addresses. Some programmers might even forget that other addresses are possible and intentionally limit what their software can handle. It could become a defacto smaller address space, making the rest of the address as complete waste forever.

That's a good point. Indeed, in a vacuum world it would be very much a problem that needs to be addressed. Right now however, there are ipv6 addresses in use that use the other end of the spectrum already. During the migration period it won't be a problem either. In the far future, where most traffic uses the new scheme, one can hand out temporary ranges from the traditional ipv6 assignments to high-traffic ASs.

And even if you don't do such measures, the rest of the address space won't be a "complete waste forever", one will just have to identify the implementations which have problems with these addresses and change them. It's a solvable technical task like any other.

Sure, if there are already address at the other end like there are by now.

> one will just have to identify the implementations which have problems with these addresses and change them

Isn't that what converting from IPv4 to IPv6 is? It's really hard.

> Also, try telling your friend over the phone,

Try telling your friend a URL over the phone! They were designed to be human readable but they're usually far more impossible than IPv6 addresses.

If you're going to complain about something, you should have an alternative solution in mind. Otherwise it might be possible that there really is no better way and nature just hates humans. Then your real complaint might be that humans are bad at long strings or there are too many devices on the internet or too many people in the world or whatever.

I missed the word "NAT" once in my previous comment. IPv6 NAT exists. Works fine, if that's what you want.

But also NPT is so much better. And/or enables several architectures with so much easier topology.

> Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade

Why would you not use DNS?

And even more: why would you use a phone? People don't call, anymore.

> try telling your friend over the phone

You're both using computers at the time. Why not send a message and copy/paste the address instead?

It's just an example. Do you know the ipv6 address of your router? The fe80 one? Likely not. 10.0.0.1 is much easier to type.

There are two scenarios though: a) you know the network and know you can rely on router.lan or whatever else the manual tells you, or b) you don't know the network and you'll have to check the gateway / route table anyway, so you can copy-paste. Or c) it's not a simple home network and you can design naming as you want / have routers documented.

Sure, 10.0.0.1 is convenient, but my router changed from 10.0.0.1 to 10.1.1.1 with a firmware update. Not relying on remembering that IP would've been better.

Thats why home routers has its own domain. mine is homerouter.cpe (this comes with the router)

Also remembering IP address does not get you so far. the last company I worked at had a spreadsheet of IPv4 address of the Jenkins boxes that we managed.

fe80::1? Yeah, I know that. It's not hard to type either, although I don't really ever need to type it because v6 has a method to automatically configure the default route.