Mynacol: DeLegacy: Forcing IPv6 at Scale

Hinzugefügt: 2026-06-06

[00:00:11]Hi everyone. Uh thanks for uh the many people that seem to be interested in this talk. Very cool. Um yeah, let's get started. Um I have a quick agenda but it's the usual thing. um a quick motivation then the actual concept then I will talk a bit about the implementation and what types of uh technology you can do. Um then I talk a bit about the problems and side effects of this. Um afterwards I want to talk about how you can create your own D legacy rules and contribute to the project. Um finally I have some evaluation on what is the impact of this? How many sites can we enable IPv6 for? And a short uh con conclusion.

[00:01:00]Um a short note about me. I'm Mino. Um you have the contact information on the site. Uh I'm a PhD student at M University and uh researching on a network security um anonymous communication just such as tour and I'm part of the BW net research project and also part of the network operations team at the university and aides from uh the university thing and IPv6 I'm also um yeah a little n packages contributor and one of the maintainers of RSS bridge.

[00:01:40]So let's talk about the problem or the moderation. Um in the end IPv6 will win.

[00:01:47]This is clear. We are now at 50% usage of clients that access Google. Um IPv6 will win. The only question is how fast and I was wondering how can we make this number go up? how we can uh make more websites accessible over IPv6 as a client. So not tweaking the website itself but the client and without any transition mechanism without any software component that has to translate IPv6 back into IPv4. How can how can we do native IPv6 as a client at least?

[00:02:25]And the other part of the story is the following. Who of you knows this interstitial? Uh just raise your hand.

[00:02:35]Yeah, more or less all of the people here. Uh it's from Cloudflare, one of the biggest CDNs out there. And uh the interesting thing is Cloudflare is really popular. Um about 20% of the internet uses Cloudflare and it supports IPv6 since 2012.

[00:02:54]But still many of the sites at Cloudfare don't use IPv6 and the basic idea is we can force these sites to have IPv6 and uh the same is true for other CDNs.

[00:03:09]It's just an example. So the basic idea is we I feel the ah now the audio is working again. Okay. Um the basic idea is we modify DNS responses uh so that the client can connect to the CDN with IPv6.

[00:03:35]I have a diagram here. It's the basic how can a client connect to a target.

[00:03:42]First it has to resolve the DNS and in this case it um queries the quad A record of example.com and uh this DNS resolver queries the authoritative DNS for example.com um which has a CNAME to example.com.cdn.net.

[00:04:01]That's a common paradigm. And then the recursive DNS reserver asks the cdn.net net name server what's the quad a record for this um domain and the CDN says we don't have a quad a record for this and now we intersect interject um after step three and rewrite the C name so we have IPv6 I will change the picture um here the new step four is uh we rewrite example.comcdnet with IPv6 6.cdn.net which is a domain that points to the same CDN but has a quad A record and then um we get the quad a record back transmitted to the client and the client can connect to the CDN with IPv6. Uh that's the basic idea here. Any questions so far? Do you understand this?

[00:04:59]Okay, looks good. Um then a quick note here uh not all websites are set up like this. There are multiple ways I've noted four here. Um first off you can just use a CDN provided uh domain for example tomot.github.io.

[00:05:18]Then it's clear that GitHub handles all the name server um and CDN functionality.

[00:05:25]Um then we have the example we've just seen. um you delegate a subdomain with a CNAME or a name or alias um to a CDN provider domain for example um as seen before and also www.cdf.de E C names to Akami internal DNS name for CDF cdf and for these two cases we can redirect the service domains in the in the background to another service domain that has C a records and then we have two other um ways this can go you delegate via static or fixed IP addresses. This can also be done at uh GitHub pages for example, but also in um the case of figma.com, it's probably what happens in the background. And um that's the most popular way Cloudflare domains are set up is you just transfer the authoritative DNS name server to the CDN and it handles all the DNS um and CDN functionality. And in the other two cases, we have no CNAME, no common domain we can match and redirect. Um, and in this case, we can use DNS 64 as we see in a second.

[00:06:48]Um, before we go into the implementation, a quick note, this is not something I found. Um some other people have found this before me and also Muru um another developer has implemented a software called IPv6 DNS server which is a NodeJS stop DNS um resolver which has a lot of custom logic and handles a lot of CDNs and services.

[00:07:14]So there is more quad A records and more IPv6 in the world. So this was already here and the thing I did was to use where possible um standard DNS functionality uh that is hopefully portable between DNS resolvers and migrate these rules and also of course find new rules. So that's the D legacy RP set project. Um you can find the repository on code. Um the URL is here and also linked in the talk description.

[00:07:50]Um yeah always welcome for contributions of course. And now I want to talk a bit more about the implementation and how this is actually working in the background.

[00:08:02]Uh maybe you're not aware of DNS response policy zones, but it's a more or less standardized way to rewrite DNS uh responses uh just by having a DS DNS zone in a specific format. Uh it is more or less supported by bind, unbound, not and power DNS. So we are quite portable here and we can match on a query name on the response IP address on name servers or client IP addresses and we the actions we can take is and the usual way uh response policy zones are used is to block the domain because it's malicious or something like that. we can drop the request um pass through. So we ignore this domain and we can also um introduce local data. So and that is the case um in how I use uh the response policy zone. So we match on the query name and introduce local data and effect we just rewrite DNS responses to another C name.

[00:09:08]You can find more info on our website there. And uh at the bottom here you can see one actual um or two actual rules uh in the project. Uh we match with a wild cloud in this case on star.cdn.cloudfare.net and cname it to one of those domains that we are we know it has quad a records in this case cloudfare.net.cdn.cloudfare.net.

[00:09:34]That's the actual internal name of one domain that works. And the second rule is just to exempt um this specific domain name from the wild card above. So we have RP set pass through in this case.

[00:09:51]And that uh brings us uh quite um away but not entirely um we cannot entirely handle this. Um, we have Akamay as one other CDN that's uh quite big and recognized and they have a slightly different setup internally and how um users delegate stuff to them and they don't use anycast as in the case of Cloudflare but they use uniccast addresses and use geodns to direct users to nearby CDN servers And an example CNAME chain here is um www.envidia.com camed to um um akami internal DNS named edge key.net is from them and that is cnamed to some identifier akamied.net net and that has an A record but of course no cut a record which we want to fix. And um yeah one of the other people in the internet uh found out that um those types of domains are IPv6 IPv4 only but there is a dual ST variant where you replace the A with DSCA. So DSC might stand for dual stack client or something like that. And then um you have a onetoone mapping for each of those domains to one of the domains that has also IPv6.

[00:11:27]Um the interesting thing is this prefix in this case E33907 has to match. We cannot just name something.net to DSCA.net net or also um one of the servers inside of this TSCA um name space 1 2 3 4 5 or something like that.

[00:11:49]If we do uh we get a certificate error um and if we ignore that we get an error message that this domain cannot be found. So you have to really direct the traffic to the right server um to handle it. And for this we have to match this uh prefix here. And I wasn't aware before but this is exactly what D names do. Uh they are more or less like Cames but don't delegate one specific domain to another but a full subdomain tree. So uh I have an example here source.net with a dname to target.net.

[00:12:29]And if you have a query for a b.source.net net. It um creates a synthesized CNAME record on the fly that cames a b.source.net to a.b.target.net.

[00:12:41]So the left part in this case a.b is copied over or um yeah taken over to the target.net source tree and that is exactly what we want. So in the end we have a rule that's um uh star.

[00:12:57]Aagamied.net to star. DSCA.edge.net.

[00:13:04]Um the problem is DNAs are not supported in DNS response policy zones. Um the reason is there would be unsolved pre precedence rules between C names that are in the global DNS and D names that are in uh the response policy zone and vice versa. So that was not never really cleared and uh all the implementations in the DNS servers just ignore or error out on D names if they are in response policy zones. So we just cannot use it in this format.

[00:13:41]uh as a workaround we can introduce those subdomains as primary zones and just say we know what to do with them and have one record which is just a dname to the other um yeah corresponding domain and we are in business again it's a bit more complicated to set up but it works um this is um these methods are for translating some common source names to some different domain names. And now we have a method that works on IP addresses. And we just use DNS 64. So if you're not um familiar with this, we can u match um on IP addresses and not on names. So we can catch setups that use static IPs, Came flattening, a name alias, uh stuff like that. and it's specified in RFC 6147 and it maps IP IPv4 addresses in IPv6 addresses often enough in um/96 subnets and often um the well-known prefix 64 FF9B uh/96 and as an example this IPv4 address would be translated to this IPv6 address um and we want to use this, but not not with a private IPv6 prefix where we route this to a peard that translates it back to um IPv4 at some point in the chain, but to translate it to working global uniccast addresses that we can route to the CDNs and they handle the rest. That's the idea. So in in yeah in this case um some CDNs answer on any IPv6 in a prefix um in the case of Cloudflare and AWS CloudFront we have such hoogles and you have to find one/64 and then you make a rule and everything in IPv4 where you know the prefix you can translate into IPv6 with some suffix which we don't care for and also the CDNs don't care for in this case and so we can just translate IP addresses um exactly so um I have an example here with Cloudflare IPv4 address and we translate it to the 26064700 and then the IPv4 uh prefix and that just works. The setup in bind is as follows.

[00:16:30]um we make an ACL where we can specify the IPv4 uh prefixes that we want to match for and then we make the DNS64 rule with the prefix and um constrain it to this ACL. Uh this is really cool. The downside is um only bind as far as know offers this functionality to restrict DNS64 to specific IPv4 prefixes.

[00:16:57]Um, and another downside is you cannot exempt some specific domain names from this functionality that have problems when you access them over IPv6.

[00:17:10]Um, the only workaround I found was to introduce knowingly broken IPv6 addresses because then the DNS 64 functionality is not activated because there is an IPv6 address. But then we have to rely on happy eyeballs and retwise from the clients to fall back to IPv4 at some point. That's not great. Of course, uh in the end um that's a list of all the services we support in some way or another in some capacity or another. Um all the major CDNs, some object storage which is quite easy and uncomplicated.

[00:17:50]uh some smaller projects and uh functions and no we I cannot translate github.com to have ipv6. I'm sorry.

[00:18:02]Um I have a backup slide if you're interested in that. Um right some open problems. I've already hinted at them. Um dn names are not supported in response policy zones which is a bummer. That would be really cool. Um, if we would standardize this and implement this in the resolvers, that would help quite a lot here. Uh, the workar around is to just set up those zones as primary zones in your DNS resolver and then you're in business again.

[00:18:37]Um then we have a lot of uh domains that uh don't redirect with CNAMES but um uh by using static IP addresses and the like and there we theoretically can match on them with an RP set IP um syntax but the problem is it only matches on a queries because then we can match on the Aquery h if we have a separate quad A query at the same time.

[00:19:10]We cannot match on the A record because the C A query has no response.

[00:19:16]Um, one way we could make this work is that cached redirects that were matched on the IPv4 address are cached for the domain that was queried. And then if a second quad a query is coming in, this cached redirect could be used and then uh fill in the cord a record. But that's probably a very unusual and not really wanted way to use response policy zones.

[00:19:47]So I'm not sure that will be imp implemented. And uh here the workaround is to use DNS 64 where possible. Um and then we have some CDNs where a more complicated logic is uh needed. Uh for example for Fastly um the IPv6 DNS server project has a um yeah somewhat complicated Molo 256 uh calculation on the IPv4 address to build IPv6 addresses and we cannot um translate this to a working config um that works with such standardized functionality in the NS servers Um there is just no portable lua scripting language that we can use here.

[00:20:37]All right. Then I want to come to the side effects. If you want to use this um I hope you don't really try to read the left side. Um there I want to access um a podcast file and one of the intermediate servers um is accessed over IPv6 which was not intended and it responds with an HTT HTTP 502 response with internal server error. And the funny thing is this happens on the IPv6 bus podcast because their host has this broken functionality.

[00:21:16]That's a bummer.

[00:21:18]And um in fact, I think the domain is for inserting ads into the podcast and they want to use the client IP address uh to use geodns to insert relevant ads.

[00:21:33]But because we are using IPv6, they cannot pass the client IPv6 address because they expect an IPv4 address and we get an internal server error in return.

[00:21:46]um this can be exempted in the RP set case but if we also use DNS64 as I said we cannot exempt specific domains from this so I have some problems based on which device I'm using uh to access the podcast that's quite unfortunate another example is from one of the um research um publishers And if you don't exempt them, they just enter a redirect loop 50 times and then Firefox gives up and says the page isn't redirecting anymore properly.

[00:22:27]And again, we can exempt this in the RP set case. Uh but in the case of um the Cloudflare DNS 64 because they use Cloudflare, we cannot exempt a specific domain and we have uh the breakage again. And finally, um I think the most humorous response here is if you want to access X.com, you get a plain text response with IPv6.

[00:22:58]if you want to access them over IPv6. Uh in fact uh some months ago um they didn't block this and you could browse x.com or twitter.com with v IPv6 um after they just moved to cloudfare.

[00:23:16]Uh but now they catch us and just refuse to respond with this uh funny error message.

[00:23:25]Cool. Then uh we come to the next chapter here which is some open source intelligence stuff. How can we um learn more about the internals of CDNs and how can we use that uh to make new rules uh to um yeah furen the IPv6 goal. Um the first thing is IPv4. It's a really cool add-on you can install in your browser and then you have this uh small yeah symbol in the top here and it shows if the primary domain you're accessing is accessed over IPv4 or IPv6 and um there are small two small other numbers um that show what which included resources um are accessed over IPv4 or IPv6 and you can expand this and you get this uh epic list of uh domains and you have an easy way to tell if you are accessing your GitLab via IPv6 or not. And this helps in other cases as well. I found that one of our GitLab servers at the university was misconfigured and you couldn't access it over IPv6 and all the browsers were falling back to IPv4 with happy eyeboards and nobody noticed until I noticed hey why I am accessing this over IPv4 I know that should have IPv6 and I contacted the administrator and he fixed it in no time. Uh so that's really cool to have a view of what sites support IPv6 and what sites don't.

[00:25:05]Um right then some other OS in sources um I grouped here of course look at the um yeah similar project from Yu if he has already um made the work to figure out how to convince CDNs to use IPv6 just copy the functionality that's how I started and a lot of the rules came to be and then I found some other worlds um search the documentation of the service of the CDN uh how the delegation setup works because they have to document that part. Um then if you have some interesting domain you can um get IP prefixes um from um yeah I lost my uh point here. uh you can often get IP IP prefixes uh from the services and CDNs and you can just look up um what ASN they use, what rooting entries they have and often enough I use btp.h.net for this. Uh also search the trunko and the certificate transparency locks lists um for server subdomains. Um that's how we found this internal cachefly uh domain to add a rule for cash flow or small CDN you never heard about but that's how I learned about it. Uh then one really cool thing that's rather new um also on Huracan Electric the BGP.h.net website there is a search tab and there you can get all the so you enter in insert an IP prefix and you get all the certificates and all the IP addresses these IP um yeah they relate to so all the domains that um direct traffic to this I to the IPs in this IP prefix and uh all through the power of certificate transparency. And finally, one website that's uh sometimes of use is uh uh does this here there you can do reverse DNS but not on the public DNS but on actual query data from some people. So you get the reverse DNS of stuff you are maybe not intended to um and stuff that's not directly linked in in the DNS system. Um right. So the yeah usual way to do this is um you notice a website lacks IPv6 and you want to change that uh via IPv IPv. Then you look up if it uses a CDN by using GIP lookup or um one of the websites to get the ASN it is hosted at to figure out uh if it uses a CDN and which CDN. And then you look if it uses CNAME delegation with tick or drill or something like that. And then you have to find a replacement domain. Um some time ago we had this cloudfill.net CDN.cloudfill.net domain. Some of that sort you have to find. Um there are these reverse DNS um websites and uh the certificate transparency logs and stuff like that can help you to uh find such replacement domains that have IPv6 set up and uh yeah uh as I as I've written and then uh you can try connecting um using IPv6 curl has a neat functionality um you want to download example.com and you add this resolve equals example.com port number 443 and then an IP address in this case an IPv6 address and it temporarily uh uses this IPv6 address for the connection to example.com so you don't have to modify your host file for a second try to connect and then remove this entry again but just use curve for And that's it. We create an RP set.

[00:29:34]All right. Um now we come to the evaluation. Um how can we figure out what impact this has? How can we figure out what uh websites we are hitting and improving by using FPV6?

[00:29:51]And um I used the full tranquil list with subdomains for this. Um uh an ID of the exact list is written here and it currently has 6.8 million domains and I just queried them all.

[00:30:06]Um I used a bind as recursive resolver and queried all the A and quad A records uh in two views. one vanilla just recursive resolver as you would at home and one with uh different setups um in in some points in some cases I have only the response policy zone set up in Alena case I have the response policy zone and the dn names using primary zones for this and in some cases I additionally add DNS64 configs to have the full package if you will And um the CDNs are detected by the domain names just like the response policy zone does and by IP prefixes um just like DNS64 uses. Um as I said often you get uh full IP prefix lists from the CDNs themselves. So you can match what domains you are testing um are using the CDN and you don't catch by name but just by IP address. And then I did a statistical analysis on the amount of additional cord a records we have here for the top 100,000 10,000 100,000 1 million and then 6.8 million domains. uh to have some um more detail here. I didn't test uh to connect to to those cord a records. So there could be server errors introduced. Um there could be other breakage that you cannot connect for some reason. Um I didn't test that and also I obviously ignored all the services I don't handle and yeah that's it. Um first off before I come to my project um I have the popularity of the services I um studied here you have the percentage of all the handle handled services in my evaluation for the top 100 domains in the trunko list um we have 36% of those that use CDNs that use cloudflare uh 10% use a cloudfront 15% use Akcomi 21% use Fastly and 15% of them use GitHub in fact. Um and the same is true for uh the top 1,000 and so on.

[00:32:36]And you see if you take the top 1 million or top 6.8 million addresses, 71.4% of those that use CDNs are using Cloudflare. So this is really a dominant player. We see this again in a second.

[00:32:53]Um right now we come to how the response policy zone and the dnames and the DNS64 performs and how many quad a records it um adds to uh this list that's displayed here. So at the top 100 uh we have um small improvements um attributed to DNA and DNS64.

[00:33:23]And as you see over time the improvements of um the response policy zone and also of the DNAs is rather small compared to DNS 64. this uh really knocks out the ball in I think the top 10k or 100k.

[00:33:44]I think the top 10k and the total additional cord a records we have is about at 10%. So a reasonable high um but also not groundbreaking. You cannot just turn IPv4 off in your network if you want to use the wider internet.

[00:34:03]All right. Now I also splitted this per um CDN or service. So we have a look at that. Uh you can see that here. Um in the case of Cloudflare, we have to say um so I splited this into the top 100K and the top 6.8 million addresses. In both cases, most of the domains in the tranqu have cord a records already and we can fill up the rest with the DNS 64 functionality.

[00:34:36]A similar case is in cloudfront but here the default cord a usage or adoption is quite low. we have 25% and 38% um depending on the sample size and we can improve this a bit with the response policy zone which is actually one single RP set rule. It's really cool. Uh but the majority again is from DNS 64 and we can just bring this to 100%.

[00:35:09]of course because um I use the same IP prefixes for the evaluation as for the DNS 64 functionality. So in the end we always come to 100% if we have a DNS 64 world here. Uh in the case of Akami um as I explained earlier the response policy zone doesn't work like that. um we cannot really do response policy zones rules because we cannot add dname records to it but if we add dname records as primary zones we can quite substantially in increase the um IPv6 usage here and in this case and and all the other cases I don't haven't found a working DNS 64 rule or um IP prefix um that brings us um Yeah, to higher numbers. Um, yeah, in Fastly's case, um, the adoption, the vanilla adoption is also rather low with 20% IPv6 usage. Um, and we can quite uh very um reasonably increase this uh with the response policy zone. um they have quite a complicated uh way of uh using internal uh names and there are many ways to set this up. There are common um names you can use but you can also um use a map name that has custom TLS settings and stuff like that. Um and also you can use static IP addresses. So there are a lot of ways to you can set up your fastly delegation. Um and with the response policy zone we can um catch quite some of them and then I didn't notice before I made this evaluation uh GitHub is quite important in the list of domain names I think there are also some uh AWS uh resources from them some fastly resources there all the domains that are on GitHub pages for example and we can actually increase this um with D names. I haven't looked into it why that is the case, but it's rather interesting.

[00:37:32]All right. Um the cool thing uh I think this project is doing um we have a subversive method to force our way into more IPv6 traffic and we just have to modify our DNS resolver for it. no extra service we have to run and it's one of the only times we force the service operators that are so far IPv4 only to handle this in some way or another because we now connect over IPv6 which was not intended and now they have to handle client IP addresses that are not IPv4 but IPv6 in some case this leads to errors as we seen um earlier In some case they just block all IPv6 traffic but they have to handle it in some way. That's a new thing I think.

[00:38:29]Um the CDNs as the middleman in all of this could prevent this method um similar to how some of them prevent domain fronting. But at the same time for now I see no reason that they introduce um prevention methods here. Um but if this becomes a real problem of the customers of the CDN so the actual um operators um they might reverse and block this functionality and then we cannot really do anything about it.

[00:39:07]If you want to try this out um during the GPN we have a public recursive reserver with all the tricks I've shown you with uh response policy. zone DNA name and DNS 64 and you can find it at the domain name here with just port 53 uh DNS over TLS DNS over HTTPS uh to insert it into your Android into your um web browser to try it out. Use IPv4 to get a sense of what websites have um IPv6 that previously didn't. for example, at least the homepage and stuff like that of Discord, for example, now works over IPv6. Um, I deleted my Discord account quite some years ago, so I cannot really test if the login still works, but um, yeah, try it out and um, if something breaks, something at Discord broke and they have to fix it in some way.

[00:40:08]And if you are on Nixon Nixos and you want to use this uh more elaborately, there is an included flake you can just add to your config. And then there are some convenience functions to enable um the response policy zone, the DNAs for specific CDNs for a for example and the DNS 64 for um Cloudflare and CloudFront again. And if not um you can set up and configure bind or unbound as documented.

[00:40:38]We don't have documentation for other DNS servers yet. Um here the setup is for unbound which is really neat. Um I have the bind setup on the next page. A bit more convoluted but um as I said bind is at the same time more powerful because we can do the DNS 64 setup. So here you add this response policy zone um rule and then you have the to add the response policy zone as a zone um again as a secondary. So you fetch this from um via um zone transfers from a primary server that hosted hosts the um zone and on the right side I have the DNS 64 setup again. So you we have ACL's with the PV4 prefixes for Cloudflare and CloudFront of course CP in this case.

[00:41:31]And then we just um add DNS 64 rules for um each of the CDNs here. And the DNA setup is a bit more complicated. You have to add a zone file manually and specify this as a premise zone. You can read this about this in the documentation. And if there's lacking something, please raise an issue, contribute by improving the documentation as I also have written here. Uh we want to support more services of course we want to improve the coverage of existing services ideally by adding DNS 64 if we find this. Um I fear for fast leaders won't work uh in the in the same way and I fear for Agamay as well. So um maybe we found already most of the things we can find here. Uh we can always extend the documentation. Uh you can also help there. And what we really would like to have is automatic testing of the existing rules. do they still work as intended? Um, stuff like that.

[00:42:45]And what really would help to drive adoption and also reduce the error proness here is to have support in bind to expan exempt specific domains from DNS64.

[00:43:01]Uh, this way we could really use this by default and just exempt the few sites that don't work over this. And finally um what we have on our agenda is to add um easy to install packages for openwrt or other Linux desktos um similar to nixos. So you can just up install the wet and somehow a setup and works out of the box. And one funny thing I thought about um the last days again you can express CNAME redirects in at block plus block lists. So it could also um give out an ATB block plus list. You can add to your block origin and your browser just do all the work. And I find find that really neat because you don't have to modify any DNS servers. you might not have.

[00:44:00]All right, then that's it already. If you have any questions, hook me up.

[00:44:16]Awesome. Thank you very much. I think that blue screen is on purpose. Yeah.

[00:44:21]Okay, great. Um, do we have questions?

[00:44:23]We have quite some time for questions.

[00:44:25]So, if you have a question, yes, please raise your hand. I will bring the mic to you. I'm not running so be patient.

[00:44:35]>> Thank you very much. Very interesting.

[00:44:37]My question is um do you know if the CDN operators are aware of this work? Seems like some of them already have their infrastructure set up that uh IPv6 support can easily be added for example with the DNS64 method. And have you tried contacting the missing ones and ask them how can can we um improve IPv6 coverage for your network using this method because it seems like some techies might not be opposed to work like that.

[00:45:04]>> If CDNs would be supported in would be interested in supporting this um for themselves. We would not need uh this DNS 64 method. uh they could introduce alternative um DNS zones or DNS resolvers also we can insert and just do the right thing. The DNS 64 method is quite a hack that works on some CDNs because they just answer on any IP address in some prefix you send traffic to because they don't care and why should they? Um, so this is not really how they would do this, I think. And I didn't contact them.

[00:45:49]I guess they are vaguely aware that this works, but also don't care as long the customers don't complain. And that's probably the reason they will never enable this by default. Um it's good that um if you um add a new domain they um add IPv6 qu a records by default and you have to to disable this and this is probably the cause um why cloudflare has such widespread IPv6 support without any modifications.

[00:46:24]Um but if there is a enterprise user that doesn't want to use IPv6 this code they will offer a method to turn this off and um won't make it super easy to circumvent this at least. Um, and if you want to learn more about the Discord case, uh, you can read up, I think they had a blog entry with, yeah, um, when we first designed the database structure, we, um, allocated four bytes for IP addresses and now it's really hard to change the database in the live system.

[00:47:02]So, we don't want to do this and stay IPv4, at least for some parts of the service. Yep.

[00:47:10]>> Yeah. Thank you for that talk and uh as you know I contributed a little bit um to your slide number 20 and also to the uh pre-leading question everyone in the audience if you use services you care about and they don't support tell them that is my take on that to add to that list tell them they don't support sometimes you get an answer like we don't care often times you get an answer. Oh yes, we put it on the backlog or the road map and then they do um we had uh some domain provider in Germany who was first in that list um because we could circumvent it um begging him uh he finally added it >> after a lot of uh asking back back and forth uh about nagging them they added it. So, >> but if you are a customer at them, tell them. And to the Fastly case, u Fastly only supports um IPv4 for the alternative name servers. That's another issue.

[00:48:19]>> The work doesn't run out so fast.

[00:48:22]And also um what I did um in a few cases I noticed that a GitHub page was IPv4 only because they use their own domain name and just inserted the IPv4 addresses. And you can often just um create an issue there. Ask them to add the Cord A records and often enough they just do this because you can say nothing will break because it's a static site.

[00:48:50]nothing can break and then yeah the world is a little a bit better.

[00:48:55]Um this might be a stupid question but why is cloudfare not at 100% if they support IPv6 and the second question would be uh edge case if you have like GitHub page behind cloudfare where in your slide of the statistics would it show up only in the front end of the cloudfare because it's the front f front frontfacing uh place or whatever or how would it be in the statistic? So to your first question um they are not at 100% because if you are a really early customer that created their zone in 2010 or 2012 or something like that the default back then was to have only IPv4 and you have to manually enable it to add IPv6 um because they don't want to break existing workflows of course. Um also if you are an enterprise or you use the API I have heard you can disable this and some enterprise want to do that as I said this code is one of those cases um that's just the reality that's why they are not at 100% um in the run setup to your second question um don't front cloudflare cloud GitHub pages um with Cloudflare because they already use Fastly. So you have a CDN behind a CDN which is not helpful. It just makes things worse. But to your actual question, if you front your GitHub pages site with Cloudflare, I will see Cloudflare IP addresses and I most of the um findings here were on IP address identification. So it would um count to Cloudflare and not to GitHub.

[00:50:56]So CL no uh content network inception not not recommended.

[00:51:01]>> No.

[00:51:03]>> All right. Any further questions? We have a few more minutes and there are no stupid questions. You can always ask a question for a friend who's not here but you might want to ask about something.

[00:51:14]It's totally fine.

[00:51:20]>> Hey. Um can you tell us more about your setup for GitHub?

[00:51:25]>> Uh yes. I hinted at it. Um, so I have this pretty full backup slide here. So we all know GitHub doesn't support every IPv6 and uh some resource subdomains for example raw.github user.content.com and GitHub pages already supports IPv6.

[00:51:46]Um, in that case they use Fastly as a CDN before. So it's not really an issue for them. um for the main github.com, api.github.com and so on domains they use their own as network.

[00:52:03]So um there is no CDN in the classical sense and they already have since quite some years actually two IPv6 prefixes.

[00:52:13]Uh the main one is this one a /29 assigned and also rooted on the um public internet and one of those addresses is also pingable but it doesn't answer on any TCP ports. I tested it. So this quite sounds to me like yeah sounds quite to me like uh they have some internal setup for IPv6 but are not willing and ready to uh open this to the public internet.

[00:52:46]There is some firewall that blocks this I think. Um maybe you've heard in the news that are that they are trying to migrate to Azure for a lot of their services.

[00:52:58]um and they already started by using um VPS's from Azure as load balancers and they are just random IPv4 addresses in the Azure space and I have not found a working method to find the IPv6 address they might have um on those VPSs so we can connect to them over IPv6.

[00:53:24]That might be a possibility. I'm not sure if it will work out and also um more to the point why they maybe don't want to do this or um by default already um there is this functionality to restrict um organizations and stuff like that to IP whitelists and all those poor corporations would have to add IPv6 white lists if GitHub would support IPv6.

[00:53:52]So um maybe that's one of the reasons they don't want to support it by default at least so far.

[00:54:00]>> Yes. Yeah.

[00:54:01]>> Um thanks for the presentation. Again a question. Why wouldn't I want to support IP IP6? So there's tech or like I mean um recursive things. I have Azure maybe Azure doesn't support IP6 and so on and so forth. But are there more business reasons why I wouldn't want to support IP6?

[00:54:23]>> I think they are in at at the end or in some cases just lazy.

[00:54:31]They still have IPv4 addresses or they can use Azure IPv4 space now and they are not quite forced yet to go IPv6. So they are cannot really be bugged at the current point to have IPv6 even though a lot of customers are complaining in the case of GitHub there is a great issue there but yeah that's the word >> GitHub >> all right >> that's a good question the question ask the question gang come I want who knows what I uh APV6 is blocked by fire on GitHub.

[00:55:21]>> So why why is it blocked? Do we know why it is blocked?

[00:55:25]>> I think they are not ready to open it up to the wider world and uh they I guess have some competent networking people um as their employees. So they really ensure that it is not reachable at this point in time. Um if they already have their own ASN, they can just do that and do this successfully.

[00:55:48]>> Any further questions? We still have three minutes.

[00:55:51]>> If not, are you still around for questions?

[00:55:54]>> Of course. Yeah.

[00:55:55]>> Will you stay for the next IPv6 talk that's coming up? Excellent.

[00:55:59]>> It's about IPv4. Sorry.

[00:56:00]>> Oh. Oh, legacy IP. Okay. I see. I see.

[00:56:03]Well, in that case, I say thank you very much and please give another very warm round of applause for minor call.