 Hallo und herzlich willkommen auf dem FEMM-Kanal und unserem ersten Talk heute von Magau. Hallo und willkommen auf der FEMM-Channel und unser erstes Talk heute. Es wurde nur von Magau gemacht, der startet mit Freifunk und hat dann startet mit vielen anderen Dingen und ist jetzt bei der C3-Infrastruktur-Team. Also ist er jetzt auch hier auf der C3-Welt und alles auf der Rückseite. Das ist also warum dieser Talk nicht nur eine Q&A ist, sondern auch eine C3-Infrastruktur-Team ist. Und Magau wird mit der C3-Welt operieren. Das ist über die IPv6 und nicht nur über die Kombination mit IPv4, aber in diesem Fall sind es nur IPv6-Netzwerke. Und sie geben ein paar Experienzen und Dinge, die sie gelernt haben. Und jetzt viel Spaß beim Talk mit Magau. Und jetzt habe ich Spaß mit dem Talk. Es ist eingeschaltet habt zu meinem Talk Legacy IP. Ja, hallo. Ich bin Magau. Danke für dieses Talk Legacy IP. Legacy IP existiert nicht mehr, aber keine Netzwerke ist auch nicht eine Lösung. Wie operiere ich eine reale IP mit IPv6-Fokus oder ideal IPv6-Only? Meine Experienzen sind die Probleme, die ich gefunden habe, die Lösungen. Und auch ein bisschen Inspiration, die du für deine eigenen Netzwerke benutzt. Also kannst du vielleicht auch eine IPv6-Only-Netzwerke schaffen. So, bevor wir ein paar Disclamers starten, in diesem Talk und auch in meiner Netzwerke, reden wir über die reale Internet. Wir haben eine AS, wir haben eine IP-Space, und wir operieren BGP mit den restlichen Internet. So, diese ganze Sache ist nicht ein Spiel. Die Operation von einer AS ist nicht nur ein Klick in deinem VM, sondern auch ein Webserver. Also, bitte denken, ob du das eigentlich machen kannst, und ob du die Verantwortung für das tun kannst. Und besonders, wenn du das brauchst, pay attention to knowing what you're doing. Also, wenn du Training und BGP-Tests hast, gibt es die AS 1042, die Virtual Overlay-Netzwerke, für das Spiel, aber bitte nicht das in der öffentlichen Internet tun. So, nächstes Talk, Terminale. In diesem Talk, ich werde ein paar Terms benutzen, das ist IP, d.h. real IP, d.h. IPv6, der 128-Bit-Variant, und wenn ich über Legacy-IP, d.h. IPv4, der old 32-Bit-Variant. Okay, so, wie hat es starten? At some point in 2020, I'm doing that for a while now, a bunch of years, in 42. I also tried doing for a while and collected a bunch of things and experiences. I also collected a lot of services that required reworking and rebuilding at some point, so I thought it might be time for a real network. So, what do I need for a real network? I will need an autonomous system. If I become a right member, I can get that. If I might need connectivity, so somewhere I need to get IP addresses and I need to bring them into the Internet. In some way there are virtual machines with ISP points. There are virtual machines with PGP upstream, so that's all possible. You need IP addresses. For real IP, that's not a problem. You can get, there are lots of them to get. RIPE will give you a slash 48 PI network, which is connected to your organization, but not to a provider that will give it to you. Legacy IP-Adressen oder IPv4-Adressen, so we have those networks. So, let's get a legacy IP. Maybe, those don't exist anymore. If you look at the RIPE website, you will see that how many RIPE members are waiting for new IPv4-Adresses. You can see that the waiting list is getting longer and longer. And apparently today there's a new high point just as yesterday and the day before. And also the used market for IPv4-Adresses is not great. You're paying around at least a 2-digit price in medium size for an individual IPv4-Adress, depending on prefix size of course. But IPv4 is for a private best effort project not really an option. So, what to do? Let's just use only IPv6, because that's what we have. That's not a problem and easy to get. What should my network do? So, I made a small list of services I wanted to host. Of course, a web server of a blog, a next cloud, a hedge-dog, which runs this passion, a mail server, so, that we will get to later. And a few other things that are needed. But if you look at this list, you notice people use it. It's not for me just for fun, it's actually something people use. So, we have just said, we make an IPv6 only net. What do if the users of the servers only have legacy IP? We have said we have an IP only net. Step one, just mal be serious. You can see this header on my blog, which says, you visit this blog with legacy IP. Maybe in the future you will have problems with availability. What's the idea behind that? You make it a marketing problem if a network for providers doesn't support IPv6. Wie gesagt, es ist nicht so ganz ernst gemeint, aber falls ihr das auch machen wollt. It's a nice student discussion, to be honest. It's not really serious, but if you want to do that, if you have the right IP or legacy IP, wenn ihr rausfindet, hat es eine Option für ein real IP oder legacy IP. Und ihr wisst, dass der Request für legacy IP war, dass es nicht so lange dauert, dass es sehr, sehr ernsthaft ist. Na ja, also Step eins, es ist ein fun Ding, aber es ist nicht wichtig, dass es so lange dauert. So, do we need legacy IP everywhere? No. That's what Step two is for. An L4 Proxy. The idea is, that a small number of boxes will have a legacy IP address. I call them gateways. And on these boxes you have a list, and they distribute the requests to legacy IP addresses on a port basis. So a TCP port 80 request comes from legacy IP. NGNX knows to which server will free IP to relate. You need one of them for every service that has a use port, which of course means that you for HTTP and HTTPS to set up a proxy. Here's an example config. You can see an NGNX stream log, that's not the standard HTTP part. It's only for layer 4 TCP or UDP. In dem Fall for 6 only, natürlich. You can specify an upstream NS und sagt im NGNX, UDP on port. And then it tells the NGNX, that for this IP address there's the UDP part. And this 10.2.3 is of course on the example. And then that passes it onto the corresponding backend. And then here there's the TCP variant. So this is really not any widgets work. So what does this look like? On the internal services that are not supposed to be viewable from the outside. So, if we have DNS, then we have a hidden primary here, which is only a singular IPv6 address, which is configured there. And that's where it's reachable, but it doesn't really need IPv4, if there are no end-users that are going to request it from IPv4. Then we have a secondary service here that is supposed to be viewable by users. So, if the user is still off the machine itself, continues to be V6 only. And then end-users will maybe also get a separate hostname, like ns1.exemple.com, and that will one for use the read address in some way, which will directly contact the host. And then there's an IPv4 address, which will go to this NGNX gateway, which is then configured to listen on this part, on part 53, of course, and will pass it on. So, how do these servers talk to the outside? Because we covered how the clients will talk to the server. So, the problem is, there are endpoints that maybe don't have real IP. There is a well-known Git-Website that is still not operable from IPv6, und so we use the same procedure as every time, which is NAT, which is the solution to all networking problems. So, we don't use NATv4, we use NAT64, is what it's called. So, we have an address translation between the IPv6 and the IPv4 address space. There are lots of talks and literature about this and how it works. So, I'm not going to go into much detail here. But, and this is also used in the telecom mobile network. And they do a bodyfought there. So, how I realize it is that I have a common prefix, which is a v6 prefix, where the entire v4 address room is represented within the IPv6 address. And the v6 for gateways will announce this prefix. So, that devices that route back there know where to arrive. And if an IPv6 only box will try to access an IPv4 resource, it will just request the DNS resolver that is able to give back the proxy address. And there are plenty of DNS servers that will return v6 encapsulated v4 addresses. And that's basically it. We can communicate from the inside out and from the outside in. So, let's have a look at the overview again. If you see our big IPv6 network, which uses OSPF and IBGP, we have a regular edge router that routes the IPv6 addresses to the outside and inside. V6 end-user will always just use that edge router and directly access the services. And there we also also see a legacy end-user. They will use the TCP-UDC legacy to v6 proxy, which is this NGNX proxy thing that I showed earlier. And then on the left side there is what I just explained, how native v6-only services can communicate with legacy-only resources, which is a NAT64 gateway, which is also at the edge of the IPv6-only network and needs a DNS64 Solver before as well. So, it would be way too nice if that just worked out of the box so ... ... was were problems und how did that solve them? Mail servers are complicated via DNS, a reverse DNS and everything has to work. On the same time, email is a very critical service. So, from the beginning I said this one will not have IPv6-only, it will get an IPv4 itself or run outside. So, think about it well if you want to run a mail server yourself. It's not very easy, it might be very tricky. To have an available and working mail server. Another problem I had with the software metric signups, which is a matrix home server for instant messaging. In general, it would run on IPv6, but the emails are not compatible with happy eyeballs. So, if you try to connect with a IPv6 address, it can't be found via legacy IP. So, it just stops working. It will not reach it. I haven't solved it, there's a GitHub issue for that. Somebody should invest some time for that. But right now it's broken. Docker is another topic. If you configure it and invest a lot of time, it will run. But you feel it doesn't. So, if you want, it can work. It's less nice with GitHub runners. I've tried integrating a GitHub runner into the IPv6-only net. But the communication with the container didn't work. If you had a Docker container or needed one, eventually you had to roll back to IPv4. So, for now it's broken. Another topic is, if you have HTTBS-Traffic, but it's not over DIN DNS. But over a directly connected VPN host it's a little tricky. Depending on how you construct it. But I didn't get around reverse proxy chaining, which is a nut for HTTP. Which isn't nice. There should be other solutions. But das ist nicht mehr so stark auf IPv6-only. So, connectivity, routing and administration. That's not very IPv6 centered. I have two Transit für V6 ist relativ günstig. Gratis V6 Transit ist zumindest 1XPVM in Frankfurt. Und dann haben ich es noch weitere Projekte mit billigem Comput also die ganze Rechenleistung. Und ich habe noch ein Projekt mit cheap computing wo ich nicht BTP habe. Da musste ich mehr, weil ich nichts Besseres habe. So, ich muss sich zwischen diesen beiden Locations kommunikieren. Also, ich musste eine Policie-Base-Routing auf der WireGuard-Mailing-Listin eine Diskussion, die ist besser für separating the view of the own network und the Hetzner Network. WireGuard doesn't support VRF right now. Und da ist eine Diskussion um Leaks zu unterbinden. Exakt. Connectivity. You want strict firewall rules so you don't want to send packets from the internal network to the Hetzner default gateway. That's because Hetzner doesn't know what your AS for Hetzner is an external network because you don't have a BTP upstream. So, pay attention to what you have. I do my routing with birdtube and those PF as a GP IBGP between larger locations. There are different options again the topic administration are you salt stack it's also possible of other tools but it really can grow fast if you don't get consistency into your BTP configs and firewall rules so make sure your system runs stable let's get to the end so what would be cool to do it would be ideal to get away from IVPVMs to our actual house to actual running metal but maybe an option for the future and also real layer 2 transport instead of using overlays would be really needed then not use all of them to you but also not really trivial and also not very cheap but if possible and if it is used productively it really should be done rather than this approach okay so let's get to the conclusion what I do it again yes, we six only with only a few legacy IP edges it really makes sense it is durable in a reasonable fashion cost wise it probably also really makes sense since legacy IP often is for legacy IP and then only having legacy IP on the edge nodes is actually also possible so the layout that I did with the IXPVMs and the tunnels is okay for private best effort things but not really suitable for productive networks anything that actually earns money for that you need actual peerings actual layer 2 transport but that's not really what the goal of this was and yeah, that's basically it thank you very much for watching and listening if you have any questions you can send me an email to rc3 at ipv6.ch es gibt leider kein q&a and that's how we're back here thank you to Magal for the talk there will be no q&a because this Magal is involved in the future but you can send him an email to the email address that was shown the next talk will be at 7pm with the c3 news shows and then networks as data sources that's it, bye this talk was translated for you by ku and oscar thank you for listening we like to have feedback for our translations you can leave it under the hashtag thank you very much and have a nice time at c3 bye