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

141–148 of 148 posts

Re: Enabling IPv6 support for GitHub Pages

#141

Post by kazen44 »

floatboth wrote: post #132
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…

Don't touch ICMP, just don't. http://shouldiblockicmp.com https://rachelbythebay.com/w/2015/05/15/pmtud/ > sniffing (and snooping?) Nothing is new here. ND is basically what ARP was. You don't disable ARP, do you?

technically, you cannot even disable ARP because of it inherent reliance on ethernet...

Atleast ND is a proper layer 3 seperation of link-layer discovery..

Re: Enabling IPv6 support for GitHub Pages

#142

Post by azernik »

kazen44 wrote: post #140
azernik wrote: post #110

Earlier quoted context omitted.

Having done some work on implementation/migration: EVERYTHING needs to work. There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much…

this comments hit up a good point, the lower in the OSI stack you go, the harder it is to initiate change. There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...). migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.

It's not about "lower".

We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.

Re: Enabling IPv6 support for GitHub Pages

#143

Post by Dylan16807 »

lazide wrote: post #88
Dylan16807 wrote: post #69

Earlier quoted context omitted.

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

That’s nice, but clearly not how the majority of the purchasing departments work right now, correct? And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.

> That’s nice, but clearly not how the majority of the purchasing departments work right now, correct?

The question was about what the company can do, talking about external constraints, so I don't really care how purchasing departments work for that topic.

> And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.

For smaller companies, yes. Except the argument was that smaller companies could get them already, while Amazon would exhaust the world supply.

Once we move into the realm of companies that make their own markets, it doesn't matter what "most people" do. Those companies can make their own choices and get whatever they want made.

Re: Enabling IPv6 support for GitHub Pages

#144

Post by ksec »

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…

Agree with every single point. I guess that is the difference from user perspective to engineering perspective.

I often wished there was just a simple IPv5.

Re: Enabling IPv6 support for GitHub Pages

#145

Post by azernik »

geofft wrote: post #129
azernik wrote: post #108

Earlier quoted context omitted.

Having implemented SLAAC and address anonymization: These are very, very simple protocols.

Oh, sure, but my point isn't about implementation complexity, it's about network architecture. SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that…

Modern IPAMs do work with IPv6 - routers know what hosts have performed SLAAC and can report that (see e.g. https://documentation.solarwinds.com/en/success_center/ipam/...)

If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.

Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.

You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)

Re: Enabling IPv6 support for GitHub Pages

#146

Post by kazen44 »

azernik wrote: post #142
kazen44 wrote: post #140

Earlier quoted context omitted.

this comments hit up a good point, the lower in the OSI stack you go, the harder it is to initiate change. There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...). migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.

It's not about "lower". We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.

mind you though, that layer 3 and 4 are somewhat interlinked.

Re: Enabling IPv6 support for GitHub Pages

#147

Post by geofft »

azernik wrote: post #145
geofft wrote: post #129

Earlier quoted context omitted.

Oh, sure, but my point isn't about implementation complexity, it's about network architecture. SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that…

Modern IPAMs do work with IPv6 - routers know what hosts have performed SLAAC and can report that (see e.g. https://documentation.solarwinds.com/en/success_center/ipam/... ) If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv…

Ah, well, I'll just modernize my IPAM, no big deal....

I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get on the network. (They eventually switched to 802.1x and no captive portal.)

Long story short, my experience is that everyone is doing at least one silly thing with their networking ("write your own IPAM" is distressingly common, for instance), and even if everyone agrees is in fact silly, it requires some sizable project planning and expense to stop doing it. Certainly a lot of people have managed to implement IPv6 just fine - a good chunk of the internet is on IPv6. But a lot of people haven't, and I don't think the primary cause is laziness.

Re: Enabling IPv6 support for GitHub Pages

#148

Post by azernik »

geofft wrote: post #147
azernik wrote: post #145

Earlier quoted context omitted.

Modern IPAMs do work with IPv6 - routers know what hosts have performed SLAAC and can report that (see e.g. https://documentation.solarwinds.com/en/success_center/ipam/... ) If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv…

Ah, well, I'll just modernize my IPAM, no big deal.... I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get o…

I mean. When it's stuff people have to do for work and they're not doing it, and that happens on a systemic level? Usually it's not "laziness", it's just that there's always lots of work and there's never enough money/man-hours.

The main point I'm trying to make is that this has nothing to do with the technical characteristics of IPv6 itself. By definition, a layer 3 protocol interacts with every single piece of network-related software out there. You have to update everything, and that's a whole lot of work no matter how you cut it. It only takes one awful hack like that MIT thing you described (whyyyyyyyyyyy) to hold up an entire migration.

(If I were MIT, I would suggest turning off router advertisements ie the infrastructure side of SLAAC, and only serving addresses over DHCPv6. Gets you an easier port of hacky shit like that.)

Post reply on HN