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

61–70 of 148 posts

Re: Enabling IPv6 support for GitHub Pages

#61

Post by est31 »

Macha wrote: post #43
throw0101a wrote: post #29

Earlier quoted context omitted.

> It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983: * https://en.wikipedia.org/wiki/Flag_day_(computing) There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994: * https://en.wikipedia.org/wiki/Commercializatio…

That's a different concern though - Promoting the whole use case of the internet vs migration from one protocol to another. If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is…

Introducing HTTPS to existing infrastructures is easy. Just terminate it at some point. It also adds a big advantage to users that their traffic can't be read by network operators. Introducing ipv6 is harder, as you need to change all your routing, logging, banning, etc. facilities to support ipv6. It doesn't add any direct advantages for users, as all ISPs still have to support ipv4.

Re: Enabling IPv6 support for GitHub Pages

#62

Post by psim1 »

cmroanirgo wrote: post #38
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…

> 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.

Re: Enabling IPv6 support for GitHub Pages

#63

Post by lokedhs »

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.

I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6:

Pinging www.google.com with IPv6:

    $ ping www.google.com
    PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes
    64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms
    64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms
    64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms
And with IPv4:

    $ ping -4 www.google.com
    PING  (142.250.186.100) 56(84) bytes of data.
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms
I have no idea why that happens. It's not on all sites though, so it's not like my ISP adds latecy to all IPv4 sites, but rather something to do with routing. The IPv4 traffic might be routed to a google datacentre further away.

Re: Enabling IPv6 support for GitHub Pages

#64

Post by lokedhs »

throw0101a wrote: post #49
Slix wrote: post #42

Earlier quoted context omitted.

> I'm used to the pseudo security that a NAT gives. In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic? On my Netgear R6700, I can't figure it out from the UI or from forum posts/help content. And without being certain, I don't want to turn on IPv6. Even though…

> In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic? Copy-pasting from a previous discussion a little while ago: --- IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4. A…

Ping will still likely work. At least I can ping all my machines on my private network. However, I'm not able to ssh into it or anything else, because all traffic is dropped.

It all depends on firewall configuration, but I think you may unnecessarily scare people by suggesting they're wide open just because ping works.

Re: Enabling IPv6 support for GitHub Pages

#65

Post by xxpor »

kevin_thibedeau wrote: post #57
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?

> What about IPv6 makes it such a chore to become widespread? Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.

The additional 12 bytes to store the v6 address might not be trivial to find as well (connection state tables in kernels, additional space in DBs). There's also MTU issues.

Re: Enabling IPv6 support for GitHub Pages

#66

Post by lokedhs »

unethical_ban wrote: post #8
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 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…

In what way doesn't Ubiquity sorry it? I'm using only Ubiquity gear at home, and my network is fully IPv6.

My router is an Edgerouter by the way.

I do recall seeing some of the configuration wizard stuff not having options for IPv6 in the past, but that's just for initial configuration anyway. Once you are done with that you do everything from the config tree anyway.

Re: Enabling IPv6 support for GitHub Pages

#67

Post by xxpor »

zokier wrote: post #23
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 think its more of a matter of perception than anything. IPv6 adoption has gone pretty smoothly imho, there hasn't been any major blowbacks or anything; for example the Google IPv6 adoption chart trend is steadily increasing. Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followe…

Someone pointed out recently on NANOG the thing that probably killed a TON of IPv6 momentum was when they missed the deadline to get it included in Windows 95. Approximately no one was on the internet before then.

(Yes yes you nerds were, but most people weren't)

Re: Enabling IPv6 support for GitHub Pages

#68

Post by BenjiWiebe »

throw0101a wrote: post #52
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…

> 2. I'm used to the pseudo security that a NAT gives. If you wish to do this with IPv6 you can with ULA and NPTv6: * https://en.wikipedia.org/wiki/Unique_local_address * https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr... > 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. For those wondering: ping works by sending ICMP(v4) echo request packets. If you wis…

Please don't block ttl exceeded packets... It will cause some very hard to troubleshoot network issues for someone somewhere sometime.

Re: Enabling IPv6 support for GitHub Pages

#69

Post by Dylan16807 »

lazide wrote: post #59
Dylan16807 wrote: post #50

Earlier quoted context omitted.

So tell your vendor you expect them to have that redesign in 4 years.

Fat lot of good that will do you with your project that needs to be completed next year or your company is hosed no? And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway. The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum…

> Fat lot of good that will do you with your project that needs to be completed next year or your company is hosed no?

You can do both.

> And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.

It depends on whether you actually want to fix it.

> The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.

Yes, which is very different from being unable to get the equipment you'd need.

Re: Enabling IPv6 support for GitHub Pages

#70

Post by kalleboo »

Forge36 wrote: post #60
wmf wrote: post #58

Earlier quoted context omitted.

So it took 15 years to build the entire Internet from scratch but it's taking over 20 years to upgrade to a new version.

It is a lot bigger now. I wonder how much IPv6 growth is net new hardware vs replacing old hardware

Lots of IPv6 growth is by new ISPs that don't have the IPv4 resources that legacy ISPs have, like Reliance Jio in India.
Post reply on HN