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

31–40 of 148 posts

Re: Enabling IPv6 support for GitHub Pages

#31

Post by smoldesu »

mabbo wrote: post #30
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?

I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have le…

I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a shitty plastic enclosure with Ethernet ports can't be that difficult. I bet there are AmazonBasics products that have required more forethought than that.

Re: Enabling IPv6 support for GitHub Pages

#32

Post by mabbo »

smoldesu wrote: post #31
mabbo wrote: post #30

Earlier quoted context omitted.

I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have le…

I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a s…

It could very well be.

But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected?

The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall.

And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.

Re: Enabling IPv6 support for GitHub Pages

#33

Post by throw0101a »

AceJohnny2 wrote: post #11
mattashii wrote: post #7

Earlier quoted context omitted.

It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients. Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer rou…

Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. Performance was abysmal, 2x-10x slower than IPv4. Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.

> Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.

And quite a quick deployment AFAICT:

> Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44]

* https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access

* https://en.wikipedia.org/wiki/IPv6_rapid_deployment

Re: Enabling IPv6 support for GitHub Pages

#34

Post by josephcsible »

unethical_ban wrote: post #27
josephcsible wrote: post #14

Earlier quoted context omitted.

How important is it for networks to provide DNS servers? Couldn't a device usually get away with just using 2606:4700:4700::1111 or 2001:4860:4860::8888 all the time with SLAAC? Also, what about RDNSS?

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.

Re: Enabling IPv6 support for GitHub Pages

#35

Post by Plasmoid »

metalliqaz wrote: post #25
voiper1 wrote: post #15

Earlier quoted context omitted.

>Rather than hide whole blocks of users behind NAT, ... which creates all sorts of routing issues. If you don't have your own publicly accessible IP address it creates all sorts of connection issues.

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.

Re: Enabling IPv6 support for GitHub Pages

#36

Post by mike_d »

smoldesu wrote: post #31
mabbo wrote: post #30

Earlier quoted context omitted.

I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have le…

I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a s…

A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones.

The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.

Re: Enabling IPv6 support for GitHub Pages

#37

Post by jauer »

mabbo wrote: post #30
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?

I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have le…

Facebook's answer was "fine, we'll build our own routers" (in the datacenter, which is where quantity comes in, and is now v6-only (with few exceptions): https://www.internetsociety.org/resources/deploy360/2014/cas...

Major tech companies have constraints, but when they decide to move, they can move almost anything. It would be cool to see how constraints and problem solving approaches differed among the FANG companies as they grappled with these issues.

Re: Enabling IPv6 support for GitHub Pages

#38

Post by cmroanirgo »

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?

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 gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true.

But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you?

3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle.

4. Firewalls require two sets of independent entries for the same service.

So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.

So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate.

Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)

Re: Enabling IPv6 support for GitHub Pages

#39

Post by blacksmith_tb »

throw0101a wrote: post #33
AceJohnny2 wrote: post #11

Earlier quoted context omitted.

Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. Performance was abysmal, 2x-10x slower than IPv4. Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.

> Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. And quite a quick deployment AFAICT: > Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44] * https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access * https://en.wikipedia.org/wiki/IPv6_rapi…

Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.

Re: Enabling IPv6 support for GitHub Pages

#40

Post by [deleted] »

mike_d wrote: post #36
smoldesu wrote: post #31

Earlier quoted context omitted.

I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a s…

A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones. The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16…

[deleted]
Post reply on HN