fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

Just leaving this one here:

~$ dig AAAA github.com

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> AAAA github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33610
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

@resingm what I think is worse is that there is no ipv6 in the GitHub CI infra. GitHub host a big part of the worlds open source project but it is incredibly difficult for those to run test suites to verify that the ipv6 actually works. So it is no surprise that GitHub open source projects seldom test the ipv6 functionality.

Natanael Copa

@resingm How can ISP adopt IPv6 if the open source software they rely on does not work with IPv6? And how can the open source software verify that things work on IPv6 if they cannot test it in CI?

The low IPv6 adoption is on GitHub.

@ncopa - I wouldn't blame GitHub alone for the low IPv6 adoption, but I understand your argumentation

@ncopa @resingm IPv6 is older than GitHub, and older than test-driven development. While GH not having IPv6 support at all doesn’t help, IMHO the real problem is how stubborn some network operators are.

I’ve seen multiple cases where IPv6 support was treated as “experimental” - in production networks, on the public internet, just because some dude at a random IX said so. We need to get more people to demand IPv6, and if possible, switch more and more things to IPv6-first. The only way we can get better adoption is when everyone stops treating IPv6 as a second thing to do, and focuses on it first.

@domi @resingm

But how do you switch to IPv6-first if you can't test it in your CI/CD pipeline?

My point is that we need GitHub users demand IPv6.

@ncopa @domi @resingm Shouldn't good testsuites not depend on internet connectivity beyond fetching the source code?
Although that's hoping they don't disable IPv6 all the way to the loopback.

@lanodan You're thinking about unit tests, but CI might deploy a new staging service and run integration tests. A service's SDK might run live tests with a staging server.

@whynothugo Nah, you 100% can do integration tests isolated, after all that's how distros do it.
That said I haven't setup GitHub CI Workflow directly myself but it would be surprising to not be able to run a service as part of the workflow, after all a typical one is running a database.

@lanodan I maintain a library to integrate with a government API. My integration tests use their staging server. I can't run their service locally (the source is secret). Their TLS stack has very specific quirks. Their API has lots of quirks too, and it changes over time. A mock service doesn't cut it (nor do I have the time for it). I need to ensure that my code works with the real thing.

@whynothugo I'd consider that a rather special case, rather than a "just an integration testsuite".
Like even when the horror that's proprietary software gets involved it doesn't means you can't run it locally for development needs.

@lanodan @domi @resingm

Unit tests, yes.

I had a struggle to get local ipv6 working in docker in github actions. I got it working eventually, but it would have been so much easier if it was enabled and just worked by default.

@domi @ncopa @resingm I couldn't even use IPv6 if I wanted to because it is completely broken on my ISP's side.

@weirdtreething @domi @resingm

Imagine how helpful it would be for you to be able to test it in CI, even if you cannot test it locally!

@ncopa @resingm someone needs to focus heavily on IPv6 address reputation databases and *good* anti-DDoS tooling for IPv6. That's why a lot of sites do not enable it.

source: I contract for one of the biggest sites on the internet and that's why we can't enable it. CloudFlare, Amazon, other CDNs, etc are all incapable of dealing with IPv6 attacks as effectively as they do for IPv4.

@feld @resingm

Aha! That explains.

So the real blame is on the DDoS hackers.