Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> There are countless threads online on forums like Hacker News, Reddit where people who never really got comfortable with idea of IPv6

It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).

Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.



> It’s clumsier than ipv4. It’s unnecessary since NAT was invented.

This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.

A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.

[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space


so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .


> so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .

And the billion people in India? The billion in China? The billion on the continent of Africa? And even in the US:

> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

It's okay for the folks that got in early on the IPv4 address gold rush to tell them "fuck you, we got ours"?


“Got in early” vs “invented it”?


> “Got in early” vs “invented it”?

PSINet/Cogent got 38/8 in 1994: did they invent it? Ford got 19/8 in 1995: how about them?

How many places and people/companies didn't have the ability to go to a RIR in the 1990s or 2000s and get an allocation because their local infrastructure (power, telecom) wasn't developed at the time? So because they got computers, fibre, smartphones later they're SOL?


They sponsored it


Can I have it on my home network connection for $2/month? I could do VPS+VPN, but that's another company to deal with, another bill to pay, and several more things to break. And more latency too.


What about you send $2 to the people in India and China who can't get a public IPv4 address then?


They don’t need one. They have CGNAT


Got it. So they are subhumans who shouldn't get a public IP anyway.


It's a shame you feel that way


Unfortunately it's you who feels that way. Because you never realized that third world countries are being hurt by IPv4 address space depletion.

The lack of self awareness is appalling.


that’s inappropriate. Speak for yourself. It’s also hyperbolic.


Why would you be typing of remembering ipv6 addresses? Representation has always been consistent, if you learn the rules, like how 1337::1/64 is a valid address.


that address doesn’t even work in the address bar


It's a valid address, just not a valid _URL_.


It’s not even a valid representation of the address (you need brackets )


The brackets are only needed for URLs, scp, and a few other things, due to the fact that ports are specified with colons. Usually you don't see them in a CIDR.


Brackets are in the RFC


I looked through RFC 2373 and found precisely nothing. Which RFC?


It's a valid adress, as a network engineer I've never used brackets.


Don’t fib


No fibbing. Network devices don't use brackets.


  curl URL Format curl -6 "[2001:db8::1]:8080/"
  wget URL Format wget "[2001:db8::1]"
  ssh Standard Login ssh user@2001:db8::1
  ssh Specified Port ssh -p 2222 user@2001:db8::1
  scp Remote Path scp file.txt [2001:db8::1]:/tmp/
  rsync Remote Path rsync -av file.txt [2001:db8::1]:/tmp/
  nc (netcat) Positional nc -6 2001:db8::1 80
  telnet Positional telnet 2001:db8::1 80.
  nmap Target nmap -6 2001:db8::1


This is kinda arguing semantics, but: The address doesn't use brackets.You include brackets to delineate the address, if the address-containing string could include colons already.

So any place that can only take addresses, not some sort of URL, should/can (of course, the program author can do whatever he/she wants!) accept addresses without delineation.


List all of the network CLI tools that need brackets or even shell escapes for ipv4 addresses.

90% of HN replies are debating trivialities to attempt to skirt the point. The point is that ipv6 usability is worse. CLI usability is a good example.

There are many benefits to ipv6, but let’s at least admit the faults so they can be addressed and encourage further adoption.


To reduce doing things twice there is NAT64/646XLAT. How many v4 addresses have you memorized, I normally use DNS or mDNS.


that reduces part of the scope for some of the customers


... and annoying casting from `sockaddr` to either `sockaddr_in` or `sockaddr_in6*` while you pass around a socklen_t.

10 years ago I was all gung-ho about IPv6, but it's annoying at every level.


Why are you casting to sockaddr_in/6? The whole point of that system is that you can just pass around the sockaddr* without even needing to have a definition for sockaddr_in or sockaddr_in6. All of the socket API functions accept sockaddr*, and if you need to get the IP or port out then you use getnameinfo(), which also takes sockaddr*. There should be little reason to ever cast to either of those types in normal use. (I can think of one or two cases where you might, but they're not common.)

Having to deal with the separate socklen_t is mildly annoying, but you can just make a little struct that holds both.


Having 2 sockets for loopback or multiple interfaces is a huge pain


Bind to '::' and you can get v4 and v6 traffic on one socket.


Not on all OSes. And it's not all good to have one less socket, there are still issues with people not expecting v4 traffic on a v6-capable socket, like described here:

https://radar.offseq.com/threat/ipv4-mapped-ipv6-addresses-t...

If you want to handle two protocols, it is not unreasonable to use two sockets.


Doesn’t work for loopback (you have to listen externally )


It works fine for me on NixOS (Linux), with a recent kernel version and no weird config options - or at least I think so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: