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

41–50 of 148 posts

Re: Enabling IPv6 support for GitHub Pages

#41

Post by chippiewill »

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…

Your arguments regarding NAT only make sense when considering carrier grade NAT.

With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.

Re: Enabling IPv6 support for GitHub Pages

#42

Post by Slix »

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…

> 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 I'm technical enough to understand IPv6. Because my printer or my light bulb being exposed to the internet is a huge risk that my router is supposed to stop.

Re: Enabling IPv6 support for GitHub Pages

#43

Post by Macha »

throw0101a wrote: post #29
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 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 a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.

Re: Enabling IPv6 support for GitHub Pages

#44

Post by sedatk »

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

I believe that ARPANET was 100% TCP/IP at most a year after it was rolled out in 1983. Its predecessor NCP only supported 256 nodes. So, yes, things take time but likely for different reasons.

Re: Enabling IPv6 support for GitHub Pages

#45

Post by throw0101a »

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…

> Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS.

This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running.

I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure".

Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out.

I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.

Re: Enabling IPv6 support for GitHub Pages

#46

Post by sedatk »

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…

> Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS

Google's ranking bonus had also been a great incentive.

Re: Enabling IPv6 support for GitHub Pages

#47

Post by ArchOversight »

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…

> Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information.

Until Windows 10 this was correct, but now that Windows also supports RDNSS in Router Advertisements that is no longer the case.

My home network has been running SLAAC without DHCPv6 for years now.

Re: Enabling IPv6 support for GitHub Pages

#48

Post by jiggawatts »

Slix wrote: post #42
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…

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

IPv6 firewalls work the same as IPv4 firewalls.

You just remove the NAT from the equation.

The default is deny.

You have to explicitly enable inbound ports.

The difference is that you connect to the device address, not the NAT gateway address.

No more port conflicts.

No more split DNS.

Etc...

Re: Enabling IPv6 support for GitHub Pages

#49

Post by throw0101a »

Slix wrote: post #42
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…

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

An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.

The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.

With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.

New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.

There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.

The security comes from the state checking.

[…]

I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer.

---

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

IPv6 firewall on my Asus:

* https://www.asus.com/us/support/FAQ/1013638/

If you want to test, find the IPv6 address of your printer and try pinging it:

* https://tools.keycdn.com/ipv6-ping

Re: Enabling IPv6 support for GitHub Pages

#50

Post by Dylan16807 »

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…

So tell your vendor you expect them to have that redesign in 4 years.
Post reply on HN