Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enabling IPv6 support for GitHub Pages

github.blog

Post reply on HN
Print view View original

111–120 of 148 posts

Re: Enabling IPv6 support for GitHub Pages

#111

Post by azernik »

api wrote: post #4
curiousmindz wrote: post #3

It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs. What about IPv6 makes it such a chore to become widespread?

Two reasons. First, it's just inertia and backward compatibility. Same reason we still use the x86 instruction set in spite of its issues. Second reason is that long IPs really are kind of inconvenient for IT and network administrator people.

IT and network admin people gripe about the long addresses, but when push comes to shove they don't actually make decisions based on that.

Re: Enabling IPv6 support for GitHub Pages

#112

Post by MayeulC »

trevcanhuman wrote: post #6
an_d_rew wrote: post #2

Thank you! I know it’s all the rage to say “gee why no v6 yet?”, but that’s a LOT of infrastructure and testing to overhaul… The effort is much appreciated!

I don’t really understand the benefits, would you mind explaining them to me ?

IPv6-only hosts will be able to connect to github pages now, if configured properly.

There are a couple use-cases for that, but it should allow cheaper VPSes, or less complicated network configuration by eliminating NAT.

If a host only needs to access GitGub and a few select hosts, it can be granted an IPv6 without setting up DHCP, NAT, IPv4 routing tables, etc.

I've been considering using NAT64 as a way to eliminate the need for dedicated IPv4 configuration at home, unfortunately I recently moved, and the current provider is IPv4-only. This infuriates me to no end.

Re: Enabling IPv6 support for GitHub Pages

#113

Post by iggldiggl »

josephcsible wrote: post #34
unethical_ban wrote: post #27

Earlier quoted context omitted.

So, I was less aware of RDNSS. That makes one of my complaints moot. DNS is critical. I'm not talking about registering an endpoint into a local DNS server (mydesktop.local), I'm talking about the endpoint knowing who to ask about google.com.

I know DNS itself is critical. I'm asking whether network-provided DNS is critical, or if using well-known DNS servers like Google's or Cloudflare's would be good enough on most networks.

Do those return the correct CDN servers matching your geographical location and/or ISP? I didn't try Google or Cloudflare specifically, but I did experimentally used some other DNS provider for a while, until I eventually ran into the problem that by doing so I got the "wrong" set of servers for anything hosted on Akamai, where the route between my ISP and those specific Akamai servers was grossly overloaded in the evenings.

Switching back to my ISP's DNS meant getting a more suitable set of Akamai servers and reasonable download speeds again.

Re: Enabling IPv6 support for GitHub Pages

#115

Post by tssva »

apple4ever wrote: post #79
unethical_ban wrote: post #8

Earlier quoted context omitted.

I dug into IPv6 a few weeks ago. If you learn it from the ground up, as if you were first learning IPv4, it truly is not more complicated than IPv4+ARP. Length of address may be a reason people don't look at it at first, but if you look at it from an engineering perspective, it makes sense. The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without…

> Also, damn every ISP and every router company that doesn't 100% support IPv6. Such as Verizon who still doesn't support it on FIOS

Verizon FIOS does support IPv6 in some areas. IPv6 support has been available in my area for a couple of years.

Re: Enabling IPv6 support for GitHub Pages

#116

Post by azernik »

trevcanhuman wrote: post #6
an_d_rew wrote: post #2

Thank you! I know it’s all the rage to say “gee why no v6 yet?”, but that’s a LOT of infrastructure and testing to overhaul… The effort is much appreciated!

I don’t really understand the benefits, would you mind explaining them to me ?

The big one is the address space expansion, which in addition to solving "can't get addresses" also makes routing cheaper and faster (can allocate addresses based on network topology, rather than on what's available). Whole they were breaking backwards compatibility anyway, they also introduced a faster way of getting initial addresses, changed headers and dropped some features to make routing easier to implement in hardware, and added some features to make annotation of packets in the network backbone during transit easier.

Re: Enabling IPv6 support for GitHub Pages

#117

Post by MayeulC »

commandersaki wrote: post #106
throw0101a wrote: post #56

Earlier quoted context omitted.

> I don’t really understand the benefits, would you mind explaining them to me ? Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list. Or break out your cheque book and be prepared to cough up $35+/IP for the privilege: * https://auctions.ipv4.global * https://ipv4marketgroup.com/ipv4-pricing/ * https://ipv4connect.com/marketplace Or get an IP…

You'd still need IPv4 to connect with the Internet.

With the IPv4 internet, that is. You don't need IPv4 to connect to most GitHub pages anymore.

Admittedly, IPv4 internet is a good chunk of the Internet, but maybe not the part of interest to you at a given point in time. http://www.delong.com/ipv6_alexa500.html

Re: Enabling IPv6 support for GitHub Pages

#118

Post by iggldiggl »

Plasmoid wrote: post #35
metalliqaz wrote: post #25

Earlier quoted context omitted.

for some use cases. for example, most home users are behind ipv4 NAT because of their wifi routers. nobody really notices a problem.

Mostly because we've invested huge amounts of engineering effort to work around the problems. The result is that for the most common use cases, things mostly work. NAT systems are optimized for a few devices to be active at a time. As the number grows they might not co-operate well. Game consoles are infamous for networking problems when you have anything other than a single machine.

And the Wifi router is at least under my control (although depending on where you live and which ISP you use even that isn't necessarily true), so I can still set up some port forwarding for my internal devices as required. Because of the shortage of IPv4 addresses however carrier-grade NAT is becoming more and more common, which is truly an abomination.

Re: Enabling IPv6 support for GitHub Pages

#119

Post by eppp »

forty wrote: post #96
curiousmindz wrote: post #3

It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs. What about IPv6 makes it such a chore to become widespread?

It's all about incentive I guess. What do they win by supporting ipv6? From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch. From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch. Maybe the ones that have the most reasons to switch are new internet services and new ISP which migh…

Not only do you have to support ipv6, ipv4 will never go away on any meaningful timescale. So even if you do the right thing and deploy it you still have the same ipv4 address constraints. There is no winning.

Re: Enabling IPv6 support for GitHub Pages

#120

Post by dx034 »

psim1 wrote: post #62
cmroanirgo wrote: post #38

Earlier quoted context omitted.

For me it's a few things that keep me from fully embracing it, & largely the problem is perception, as others have noted. 1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin. 2. I'm used to the pseudo security that a NAT…

> Last time I checked, IPv6 was just so wrong... > I'm used to the pseudo security that a NAT gives > my poor overloaded brain doesn't really want to have anything to do with You've certainly made the point that you are too lazy to learn. Otherwise, you haven't made a case against IPv6 at all.

The point is that many people are too lazy to learn a more complicated alternative to something simple they've used for a long time. And that's why ipv6 still hasn't taken off in many areas.
Post reply on HN