Hacker News Reader

Comment by hkt | Hacker News Reader

Honestly, having worked for a hosting company in the past that was fastidious about IPv6 support, I can say a couple of things:

* It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6

* It is much, much harder to work with than IPv4 and I don't believe this is only a lack of exposure

* Dual stacking is expensive and requires staff to pursue training with very uncertain levels of reward

IPv4 address space shortages.. could have been addressed by doubling the number of bits in an IPv4 address, rather than throwing out the many tools that already worked.

The last point in particular is heresy to network engineers, but perfect sense to commercial types. Adoption should be cheap, if not free. The huge up front human cost of training people to operate IPv6 is uneconomical. A 64bit IPv4.1 would be fine for decades.

View on HN

Where would these extra 32 bits come from? This simple IPv4.1 would still require all networking hardware and software to be updated. The protocol would also not be backwards compatible and people would still want dual stack. I imagine adoption would not be that much easier than IPv6 adoption, while missing out on the additional improvements that come with IPv6.

> while missing out on the additional improvements that come with IPv6.

Can you give some examples of what these additional improvements are?

One is a much smaller full global routing table.

Well, the obvious one is having 2^128 addresses instead of just 2^64 addresses.

There are a few. Things like the way addresses are given out (appending your Mac address to the local prefix), large address spaces (IPv6 could number every atom in existence and then some) which then permits getting rid of NAT, and especially CGNAT (carrier grade NAT).

Generally speaking the administrative hacks which enable the internet to keep going as-is can go away. NAT in particular breaks lots of applications which is why STUN/TURN servers are needed for many VoIP applications today, so that two NATed clients can talk directly.

The address space issues mean that even if the registry gives out silly allocations (like the UK's MoD having a /8) the space is so near infinite that it won't matter. Even the most incompetent governance can't exhaust the address space.

Appending MAC to address is a privacy nightmare and is going away with privacy extensions. (I dont want people to know what NIC i have and potentially track me by looking up who bought it).

Because of that DHCP may be needed and ARP as well... nice right?

Getting rid of NAT is also questionable and there are now tools to do NAT with IPv6. So common sense and learned practices win. (I still prefer NAT and firewall, dedicated servers can have port forwarding or separare ip allocated)

Address space is the only feature worth anything as original poster mentioned.

This is a nice read on needless issues due to redesign of working protocol: https://blog.bimajority.org/2014/09/05/the-network-nightmare...

There is no use for NAT under IPv6 at all. It's sole purpose was to work around the IPv4 address space shortage. Any perceived security benefit was coincidental. NAT should not do the job of a firewall.

NAT hides all devices I have in my network from the world.

Nobody from the outside will know who made request x from the n devices in the network.

NAT is mainly privacy/obfuscation.

Can you do that with a firewall?

Another use case is connectivity:

- digital ocean gives 16 ipv6 addresses, how can I vpn through it with more hosts without NAT?

- me as a lone node on another network want to host a VPN but have a limited set of IPv6 addresses available.

- tethering

Note: I will actually be setting up a network with NATv6, DHCPv6 and a firewall in about a month, so I do need it, and since tools are available, I am not the only one.

> NAT is mainly privacy/obfuscation.

That is not the original purpose of NAT. What about IPv6 privacy extensions?

> Another use case is connectivity:

Ok, there might be valid use cases for NATv6 (I am not an expert), but it shouldn't be necessary for typical consumer home networks.

I have no problems with NAT as long as it a) doesn't block incoming traffic (that is the job of a firewall) b) doesn't perform symmetric address/port translation (breaks peer-to-peer applications).

Not the original purpose of NAT, sure, but it achieves that goal much better then IPv6

Privacy extensions are a hack and still uniquely identify someone even if it changes once a day.

NAT hides them all the time.

If I have 100 nodes, good luck identifying them over PNAT as an ISP, without PNAT you have nice tags per each node... they change once a day but you match to last days traffic.

Onto connectivity:

a) block incoming traffic - sure - blocking with firewall, NAT is redundant, its a poor mans firewall BUT if you misconfigure the firewall or is disabled, you are screwed, whereas NAT just works.

b) break peer-to-peer applications.

Port NAT is needed for privacy, so this is a given.

I also like it breaking peer-to-peer apps I only want specific nodes to be able to host stuff if ever.

For home networks STUN/TURN works just fine without having external parties know who is placing the call.

STUN doesn't work for symmetric NATs and TURN is not a solution (the traffic gets relayed over the server, which defeats the purpose of a peer-to-peer system).

Port restricted NAT is sufficient: it serves the actual purpose without breaking peer-to-peer systems.

Note: I'm currently developing a peer-to-peer app.

> Because of that DHCP may be needed and ARP as well... nice right?

ARP is not a thing in IPv6. NDP is, and has always been, a required part of the spec.

(I agree with the rest of your post)

Dual stacking with 64 (or more) bits and 32 bits would otherwise use the same software. It would be cheaper, require less training, and require less development. It would therefore not face the old, established IPv6 problems covered in the article, and could even treat the old IPv4 ranges as a /32 within the 64 bit address space. Rather than being more than twice as expensive in terms of expertise and development, it would be nearly as cheap as doing nothing.

I'm sorry, what? Extending the bits in IPv4 will break compatibility completely. Everything will need upgrades just the same as to support IPv6, so you might as well go all the way at that point.

How is it much harder to work with?

It's a minor detail, but an IPv4 address is easier for humans to use.

It's easier to read, type, remember, share over the phone or even just plan with in a spreadsheet.

My Danish phone number is 10 digits, including the +45.

It would be pretty ridiculous to limit the number of phone connections in Japan by forcing them to use Danish-style 8-digit numbers, but that is the situation with IPv4.

I'm not arguing against IPv6, just explaining how IPv4 can be easier to use.

There is a weird persistent idea that all anyone really needed to do was "extend ipv4 addresses" and everything ipv4 related would have remained compatible.

No, it still absolutely would have completely broken everything and anything that used ipv4, all the tools would still need to be thrown out.

There is basically no way such a proposal could work and maintain any sane level of compatibility.

Its evident right on its face, how exactly would an ipv4 only tool connect to a 64 bit "ipv4.1 address" ?

Maintaining compatibility was never an option. But the most sensible solution to running out of address space is simply to extend the address space. Instead IPv6 decides to change the format into something which is not really human readable, and decides to kill NAT as well. Which was really a terrible decision imo. I like NAT, I like having addresses that I can remember, and I hate the idea of having a unique globally routable address for every device.

The primary argument for adopting IPv6 is that IPv4 will be exhausted. Not that there’s something good about IPv6 that I would want to have. Personally I hope it never succeeds in getting sufficient adoption, so that eventually we can have a good IPv7 that’s just a bigger version of IPv4.

That's not all that IPv6 changed. There is a reason even places like google cloud have not implemented ipv6 (and these are huge scale players). They changed so many things around the protocol that you need new firewall experts, new configuration experts etc etc

That's right: network engineers who speak IPv6 reliably enough to deploy it are rare. Network engineers brave enough to deploy V6 only are even rarer.

What do you like about NAT?

Do you admin a medium or larger network? Despite the strength of your comment it also illustrates some ignorance.

"No way", "weird persistent idea".

This despite many reasonable people suggesting it.

Deploying IPv6 at scale is deploying a totally different protocal. What is irritating is that it's not just a larger set of bits, everything changed making adoption and tooling MUCH much harder.

"All the tools would need to be thrown out"

Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.

From address assignment (3 ways now) to the dynamic address privacy extensons (don't actually play well with IPSEC configs) to doing renumberings on prefix changes (100% nightmare) to all the training / learning new things (costs money in bigger orgs) they seem to have purposely made this change extremely hard.

Good news, I'm on board more or less with the migration at this point, and if I am a good marker of average reasonable interested in new things but not wasting tons of time then this is a good sign.

But boy they could have made this whole thing easier

> "All the tools would need to be thrown out"

> Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.

Exactly. ARP64 and DHCP64 etc would be minor modifications and much easier to pick up.

There were proposals for backwards compatible addressing schemes. But they were rejected for a "clean slate" approach. Almost 30 years later, we can see how successful that was...

EIP (Extended Internet Protocol) [0] was proposed in 1992 as a replacement for IPv4:

"EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers.

When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period."

[0] https://www.rfc-editor.org/rfc/rfc1385.html

I didn't know this was a thing, but it is always a pleasure to know people thought of something like this when I was a toddler.

IPv6 can do that too though! 6in4 is exactly equivalent to the proposed EIP extension. EIP still splits the internet into the old legacy v4 internet and the new EIP internet that cannot communicate with the old internet, since while you can send packets to a v4-only host it won't know what to do with it. You need to preserve this extra information - and IPv4 simply cannot do that. You cannot fit more than 32 bit of information into 32 bit..

This proposal essentially ended up as part of v6 in the form of 6to4. 6to4 uses an L4 protocol rather than an IP option, but that's more or less equivalent (and since there are a fair few routers on the internet that drop packets with unknown IP options it ends up working better).

But v6 doing something has never stopped people from complaining that v6 sucks for not doing the thing in question...

A huge part of that is due to BSD Sockets, which require in-depth application support for any difference in connection parameters.

Funny enough, to the last point, someone drafted an IPv4+ spec that does something like that.

see https://tools.ietf.org/html/draft-tang-ipv4plus-03

Basically adds an optional area code to encode more addressable bits.

> It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6

I mean if you're addressing mobile, IPv6 hosting means skipping carrier NAT64 for at least t-mobile and jio. Probably other carriers too.

Generally high chances you'll get better connection with any LTE network, as having only v6 to the mobile terminal (phone/modem) is much cheaper - which drove v6 adoption heavily.

The extension to a 64 bit address with few other changes was called SIP and was proposed in 1992 (!).

https://tools.ietf.org/html/draft-historic-simple-ip-03

TUBA, which used existing technology and tools to support 18-20 byte addresses (yes, byte, not bit) was ready and implemented on two different platforms by ~1991.

Reply on news.ycombinator.com