Did IPv8 have any decent ideas?

Añadido: 2026-05-07

[00:00:00]So, every time I talk about IP version 6 on this channel, I get lots of IPv4 shells asking things like, "Why didn't we just add one or two more digits to IPv4? Why do we have to change the whole protocol?" And well, ignoring the fact that IPv6 already did just add four times as many digits to IPv4, someone on the internet claims they've got it all solved with IP version 8. He says, and I quote, "No existing device, application, or network requires modification. The suite is 100% backwards compatible.

[00:00:33]There is no flag day and no forced migration at any layer." So, ignoring the fact that he's actually wrong here.

[00:00:39]His protocol is not backwards compatible because he's got a new wire format and about 15 different core internet protocols he wants to modify. Why can't we just modify IPv4 to add more digits?

[00:00:50]Why did Jaime Thne have to write this draft that everyone's gone absolutely wild over on the internet for no good reason? And could we take one of his only good ideas and turn it into a working prototype with IPv6? If that interests you, then come along on this adventure.

[00:01:07]So, time for classroom with Apple, I guess. So, here we have on your screen.

[00:01:13]This is what the contents of an IP version 4 packet look like. So we have version IHL type of service total length identification flags and fragment bits time to live protocol header check sum and source and destination IPv4 address.

[00:01:31]So taking a look at this where are we going to put the extra bits? So hypothetically we went from adding four decimal digits to six 192.168.1.1 or something like that. Now we need to fit 32 extra bits in this. And our addresses are now 48 bits long. So they don't fit in the 32-bit fields here, do they? So maybe we stuff them on the end, make the packet four bytes longer. So now our IHL goes from 5 to 6. That is valid. But what does someone speaking IPv4 do with this extra information here? Are they going to look down in these extra bytes and say, "Oh, I need to append two extra bytes on top of my four byte address." No. They're going to use a Uint32 as their IP address in code. Ignore these extra bits and we're stuck where we were before with IPv4.

[00:02:20]Now, actually in IP version 3, before version 4, they proposed using a variable length address of between 1 and 16 bytes including the length fields in the IP header. If they would have stuck with that, we could have just made the addresses longer and everyone should have been able to deal with 16 byt addresses. However, for routing reasons, it was decided in the 80s with the upcoming of ASIC based hardware routers that we needed to be able to decode this packet entirely in hardware without any software intervention for routing to work at scale. Now, even today, today your home router probably can handle a million packets per second. So, if your home router is doing a million packets per second, how much is an internet core router doing? And how fast does it have to be able to handle each packet? It's on the order of a dozen clock cycles. So if you have a processor running at say 5 gigahertz, each herz in there is a clock cycle. And a high-end router ASIC might be processing packets in a dozen clock cycles. That's how many packets they're processing per ASIC. By the way, per forwarding path, AS6 will have one of those for every single port in some cases. So, what does IPVA propose? He proposed this guy right here. It looks a lot like IPv4, but he added two new fields, the source ASN and the desk ASN.

[00:03:45]So, note that this is no longer compatible with IP version 4. Our existing IP version 4 hosts don't work, and we've added 32 extra bits of address space and made an incompatible protocol.

[00:03:58]So, how does he try to bridge this different packet with the original IPv4 packet? So, maybe Jamie needs a little bit of a history lesson on why IPv8 could never work and why we learned this like 30, 40 years ago. So, 1991, the IETF realizes that IP version 4 cannot scale big enough. Now, think about how forward thinking this must have been in 1991. Worldwide web, the web browser, the world's first web browser was less than a year old. The dotcom bubble had not started yet. Companies were starting to use IP to transfer files between their different computers or other protocols like Apple Talk, DeckNet, IPX, all of those were on the table back then. The Telos were still big on ATM. I think they weren't even adopting ATM yet. They were still predecessor to ATM, whatever that was. So they're all about circuit switching over TDM lines, synchronous optical networking. IP had a very uncertain future and if it was going to take over, it had to be able to scale and IPv4 just couldn't. So in 1991, they started researching other options. One of the first options they came up with was classless interdommain routing or cider and BGP4. And this gave them the option of much more flexibly allocating the address space we already had in IPv4. But even that would not be enough. So they would need to start researching new protocols and by 1994 they decided that they were going to go with IP version 6. So imagine hypothetically we have two computers.

[00:05:28]They could speak the old protocol IP version 4. They could speak the new protocol which we'll call IP next generation or IPNG or they could potentially speak both IP version 4 and IP next generation. So given that set we have nine possibilities for how they could talk to each other. Now generally if both of them support the new protocol IPNG they'll prefer that. So that's four of our cases. Now if they both support the old protocol IP version 4 then they'll use that. That's three of our cases. But now we have two other cases where a client wants to talk to a server from IPNG to IPv4 or reverse where a client wants to talk to a server from IPv4 to IPNG. And in this case we need some sort of translation.

[00:06:12]Now this is nothing new. They realized this way back in 1994 and so did Jamie independently and that's why he developed a translator called Xlate 8.

[00:06:21]So in fact his IPv8 protocol isn't backwards compatible either because he's using translation and he's also relying on DNS for that which is a bit of a hack but not an unreasonable hack but still a hack. So fundamentally if we want to move from IP version 4 to a new version we will have to deal with old IP version 4 devices. They knew this back in '94 and Fortunately, we're still dealing with that today, 30 years later. But if we want to do any translation, the burden of translation is always on the newer protocol speaker, at least still is today. So, we need to translate those two cases where we have an IPv6 client talking to an IPv4 server or an IPv4 client talking to an IPv6 server.

[00:07:07]Okay, back to Professor Appalard here.

[00:07:09]Four. How do nodes on the internet discover each other's IP address so they can communicate? So imagine that I as a client wish to establish a connection with a server with this address 2 AOF B240 1000 col 420 as a router and even as a NAT an IPv4 the network doesn't know how I discovered that address I could have used any higher level protocol any application protocol I could have hard-coded it there's a whole bunch of options for how I figured out that I want to connect to this address. And in general, we expect the network layer to establish this connection regardless of how I figured out that address. So maybe that address was in DNS. Maybe it resolves to like any.applar.fe for example. So in that case, maybe I looked up in DNS that name and I got back that address maybe. Or maybe we're doing some sort of peer-to-peer matchmaking here.

[00:08:12]Maybe that's your IP address and you send it to me over a chat. So, I'm connecting to it something like that.

[00:08:16]Maybe WebRTC.

[00:08:18]So, if I were to restrict you to only using DNS to find your addresses, you'd be in a bit of a rough spot if you wanted to use WebRTC to do say like a Microsoft Teams chat between each other.

[00:08:29]Everyone loves hating on Teams these days. But Jaime's IP version 8 draft does exactly that. It specifies that between IPv4 land and ipv8 land, we must have a NAT because everyone knows that NAT's the only solution that works securely, right? So at this NAT, we don't allow a mapping to exist between the IPv4 world and the IPv8 world unless a DNS record is pulled up that suggests it. So the only way you can communicate is by DNS. So essentially, he's taking all of the peer-to-peer protocols and well, a whole bunch of other protocols, hard-coded addresses, DNS resolvers, VPN, stuff like that that don't rely on DNS and just breaking all of them right out, which sounds like a bad idea, but it's something we've already actually done for a while in IPv6 called DNS 64. So with DNS 64, we take the DNS record that's an IPv4 address and we slap it into an IPv6 address and using that we can communicate with IPv4 servers over an IPv6 network. And this actually works really well. And there's actually only a few services that break pretty much peer-to-peer VoIP stuff, which is what we thought because those don't use DNS.

[00:09:40]Now the solution to that in IPv4 to 6 was to use what's called a customer side translator or seat. So that's a Damon that runs on the IPv6 only system to transmit IPv4 packets back into IPv6 packets. And that also works really really well. But in Jaime's scenario, he hasn't thought that all the way through.

[00:09:59]So an IPv8 that would probably break a whole bunch of peer-to-peer applications. That is still a decent idea if we need to connect legacy IPv4 only systems to a broader IPv6 world.

[00:10:13]And let me explain how. So, let me draw you guys a little picture of what's going on here. Same thing works for IPv6 as IPv8. And since IPv6 is actually widely adopted right now, I'm going to mention IPv6 and IPv4 going forward in this video. So, imagine on here I have my network. I have all my clients on the network that I manage. They might be able to speak IPv6 or IPv4 or both. On the other side, I have the servers.

[00:10:41]These are the people that are accepting connections. They are other networks.

[00:10:45]They again may implement IPv6 or IPv4 or both. And then in the center these are my peering connections. So on the internet we have a whole bunch of autonomous systems. These are the very large networks. They are peering with each other. And these peering connections could use IPv4 or IPv6. But the current standard is that all of these connections must be IPv4 capable.

[00:11:08]So currently most peering networks are actually totally separate IPv4 and IPv6.

[00:11:13]Some peering networks are starting to do IPv6 BGP sessions that also carry the IPv4 routes instead of running two separate BGP sessions. But even that is still carrying IPv4 traffic as native IPv4 packets. So what I mean by that is say on my client side I want to get rid of IPv4. So running dual network stacks is a lot of operational overhead. Obviously it's not desirable. So get rid of IPv4 and just do IPv6. But now I can't get to anything that's not accessible over IPv6. So the problem. So I would have had some NAT in IPv4 anyway. So let's bring that back and we'll call itNNAT 64. So now with that all of my V6 clients can address the whole IPv6 world and the whole IPv4 world via NAT 64. So this is a very widely deployed architecture. It's used by I would say probably at least half of mobile service providers around the world like 4G 5G stuff. And the architecture is called a 464XLAD. So across the provider's core network, all of the traffic is IPv6. And on the server side, as a server network, I could do the same thing. Maybe I don't want to run a whole bunch of V4 sessions through my data center. I don't want to have V4 on every interface. It's a lot of addresses wasted, things like that.

[00:12:25]So maybe I'll have all my servers on V6 only and I'll translate for them with box called Sless IPCMP translator or SIT. This architecture is also very widely deployed. It's called SIT DC. So in this architecture, I take all of my public IPv4 addresses instead of wasting a bunch of them on routing interfaces and loop backs and what is it the broadcast subnet broadcast address all that garbage we assign each IPv6 specifically to an IPv4. So if a if a request comes in like 203.13.5 we know that translates to a very specific IPv6 address of a specific server the request goes on through. And so we can have a whole bunch of V6 servers and when they need to talk to and from the internet, they each have a specific V4 address they egress through.

[00:13:11]And so this architecture also works very well. So both of these architectures work super well today. But the problem is we're carrying forward IPv4 indefinitely on the peering networks. So since we're expecting we're placing the burden for translation to IPv4 on every single IPv6 network that wants to be IPv6 only that means that all the networks that are IPv4 only are essentially getting carried along by everyone else's translation. They're not forced to progress. So if we wanted to flip the script and say we expect everything to default to IPv6 and if you want to continue operating IPv4 it's on you to provide the translation then we need a bit of a different technical solution and those solutions are much less well tested which is why I'm making this video. Also IPv6 is now officially the majority protocol at least on weekends. So Google has a tracker of IPv6 that's been running since I think 2012 and they have now started peaking above 50% on weekends. That's cool because most home and personal networks run IPv6 and most business networks do not. So that's showing that on weekdays when people are connected to business networks, IPv6 adoption is a little bit lower. Now on the server side, the internet society has a measurement of how many of the top 10,000 websites support IPv6 and that number is also at 50%. now too. So both on the client side and on the server side, IPv6 is now edging into the majority protocol. So let's move into this hypothetical world where we would like to deprecate IPv4 on the peering relationships. Maybe IPv4 addresses are still tracked and sold as a database for people that have legacy needs, but maybe we're moving services now to run on IPv6 only. And if you can't support IPv6, you just can't access more and more services yearbyear.

[00:15:03]We've already seen mandates from some governments to force IPv6 translation by a certain date. The US Department of Defense has been trying for over a decade now to get rid of IPv4 and their networks. Those aren't exactly publicly accessible, so they have a little bit more of an advantage, but we're not I'm not the only one thinking this. So, how would it go if I have to provide legacy IPv4 to a client network into a server network? Now on the server side, it's actually relatively easy. Now, say I'm a vintage collector and I want to run maybe an old web server from the 90s.

[00:15:35]There's a great guy called the serial port that has been doing this. Maybe he needs to keep IPv6 access to his IPv4 only server and he can also use sit DC for that. So they mentioned the architecture I mentioned earlier that translation is birectional. So he could take a pool of IPv4 addresses and assign them to IPv6 addresses and whenever a connection comes in over IPv6 it gets transited IPv4 and the connection works.

[00:16:00]Now the problem there is on the IPv4 side we don't know what to use as a source address. So if my client comes in from an IPv6 address what is that source address look like for him? But that solution's already been sort of found.

[00:16:12]Taigga has a solution called dynamic pool. This will basically pull addresses out of a local subnet to use for return path traffic. And this works pretty well. So if you have an IPv4 only server, you have something that's IPv4 only, we can make it work on the IPv6 network on a onetoone basis. Take individual IPv4s and map them into individual IPv6s.

[00:16:33]And that is a a solved problem.

[00:16:36]The problem that's not solved is the client side. So maybe I'm a collector of vintage SGI workstations, for example.

[00:16:42]Those are some very beautiful computers.

[00:16:44]I think so. And maybe I want to keep using them to browse, I don't know, 4chan or something. That's a pretty basic site. So, if I want to do that, I need to be able to make HTTP requests to hypothetically an IPv6 only server. And so, how can I do that? And this is where the IPv8 DNS idea comes in. So my idea is that this legacy computer that only speaks IPv4 makes a DNS request for an A record. Now there's no A record available because the site's only accessible over IPv6.

[00:17:17]But we could again pull an IPv4 local use number out of our ass, return that to the client, and then create a mapping between that address and the IPv6 on the fly. Similar to what we do in sit DC for the return addresses where we just pull them out randomly. The difference here is we're basing this on DNS. So now we've tied this functionality into work with DNS, but as a sort of backwards compatibility mechanism, that might give you a couple more years to a decade to help slowly transition your really old stuff.

[00:17:49]So since the people who have an actual excuse for not migrating to IPv6 are the people that are dealing with old vintage technology kind of stuff like this, this is a 2007 white MacBook Intel Core 2 Duo. It's running Mac OSx 10.5 Leopard, which came out in 2007.

[00:18:08]So, this being almost 20 years old would have an excuse to not support IPv6. So, I thought I'll hook this up as my test system. I'll set up a virtual machine to run my translator software, show you guys how it works, then we'll maybe browse some modern websites over IPv6.

[00:18:24]And actually, I learned that um IPv6 is not the problem for this laptop. So I plugged this guy in with an Ethernet cable to my regular LAN which does V4 V6. He came up with a V6 address just fine. So he had no problem doing stateless auto configuration. I can ping Google IPv4. I can ping six Google IPv6.

[00:18:44]Great. Um now where this falls on its face is being 20 years old. I'm a bit outdated on my cipher suites. So the version of Firefox that's on here. I'm not sure what year it's from. I guess I could look and see. It's also in Finnish, which I don't really speak. Um, so anyway, it can't load any modern website because it doesn't support the right TLS versions. I tried SSH to see if I could SSH to my Proxmach system and work from there and it didn't support any cipher negotiations either. There was nothing common found, which I kind of expect. So, I guess the lesson here is if you're actually using old vintage hardware in an IPv6 world, you're probably going to have more problems than just IPv6 compatibility. There's probably some other things going on, but I guess I will progress ahead with my modern laptop and I can show you how we can translate IPv4 only devices like this like I thought this would be and get them running in IPv6 world. So, so I'm back here with my modern MacBook and it's time to show you guys sticks, the software I developed. So, as some of you may know, I am the new maintainer of Taigga, an open- source stateless IP and ICMP translator. Link up here to the GitHub. And so with Taigga, I can translate V4 and V6 packets between each other based on a set of mapping rules.

[00:19:59]So this could mean encoding the V4 address into a V6 prefix with RFC 6052.

[00:20:05]Could mean a direct one to one mapping with a config file. And Tiger can do either of those. Tiger also supports a dynamic mapping where a V6 host with an unknown with no mapping entry can get a dynamic V4 address created. This helps with server implementations. We're not going to use that today, but it's something else it can do. And so what I've done is I've written a corresponding dam in Go since I've been learning Go recently. And this basically acts as a DNS server and it generates Taiga config files with the right mappings and then reloads Tiga. So essentially all I got to do is install the dependencies. So I need git so I can clone the git repositories. I need build essential which gives me make and GCC and I need that to compile Tiger. You have to use the latest version of Taigga not the version that's in any package repos. And then um I need golang go so that I can compile a go binary. So let's go ahead and do that.

[00:20:57]By the way, all the instructions are up here in the GitHub page. So you can see the my best attempt at green text in uh GitHub readme and an actual setup guide if you want to read that. So we'll just copy and paste some of this stuff. So now a bit of what my config looks like.

[00:21:13]So I'm assuming this system is acting as well could be acting as a client side translator or maybe not I guess. So the system on my virtual machine will have IPv6 access to the world. So I need to tell it what interface that's on and what the DNS servers we'd like to uh use as our upstreams that are going to be IPv6. Um then we need our downstream interfaces. So this is all of our client side subnetss. I've decided to use 192.168.46.024 for that. So in this case, my stick system is going to act as the router and also the DNS. So it's going to take the one address, which you have to configure on your own in Linux. It's going to bind to port 53 for DNS on that port. Clients are expected to send their DNS traffic there. So it can create these binding entries. Then I'm going to use the 10/8 network as my dynamic. Um, so if I need to do any IPv6 outgoing stuff, I can map that into the 10 region temporarily for clients. So let's look at the config file. So, we got a config file here called sticks.yamel.ample. We'll just copy that over and edit it. So, I've got a config here that um I guess is my example. So, I'm binding on port 53. My upstream DNS is going to be 2620 FF.

[00:22:26]That's quad 9. My legacy space is going to be 10/8. We could synthesize only what we have to or we could synthesize as much as possible. Uh Tiger binary installs here by default. uh if we have pref64 available we can use that as well. So if your network has nat 64 this will also set up as a 464xlat seat. So IPv4 literal and stuff get translated on across and actually a lot of traffic would get translated this way as well if you weren't using DNS46 or Sharon as I'm guess I'm calling this now. Uh you do have to specify something here or tiger won't start. So 64FB/96 and then upstream I need to put an IP address in here and downstream I need to put these ranges. Now I've set it up to do proxy neighbor discovery. So it'll sit on your LAN and proxy ND on behalf of all of the IPv4 clients. If you're in a routed network, you probably know how to deal with this in a different way, but this is an easy demo for most people. So I basically just have to put in my IPv6 subnet here. And then I guess we can take 69 for Tiga, 4600 for my network. So I'll just copy this guy. And then I actually need an ETH one and ETH2 I think. So now I have a uh ENS19. So I can go ahead and set that up. Okay.

[00:23:48]Adding proxy ND entries using sticks as working directory. Launching Tiger listening on port 53. Okay, that looks good. So, I should just be able to say ping forgoole.com.

[00:24:02]And uh there we go. It's working. And it even did reverse DNS correctly for our 10.0.0.1 address. So over here we can see what it did. So we got a quad a query, got an answer. It then looked that up in database and then find it. So it created a new map entry for 10.0.0.1 and then added that to Taigga's map file. And it can also reverse the pointer record too. But now that this mapping entry is created, I can reverse it as well. It's not doing reverse DNS in this case, but um that works fine too. So obviously this is just a proof of concept. It's not something that I think is production ready yet. Taigga is absolutely production ready. If you want to run 464xlat, sit dc and those sort of deployments. Taigga is great for that.

[00:24:49]Uh Juul is also an option on Linux.

[00:24:51]That's a kernel module out of tree. It's really quirky, but if you're doing NAT 64 specifically, Juul is good for that.

[00:24:58]Taiga is good because it's so universal in all the different roles it can fit as it fit in this role today with its magic map file mode. So, this seems to be working pretty well and I'm happy that I got this uh tested in just a couple of days. So, that's my contribution, I guess. I was thinking about submitting this as an IETF document, so I might still do that. I guess you'll see on the tracker if that comes through or not.

[00:25:23]Um, I don't really want to burden them with a bunch of bad ideas because I know they really wouldn't like that. So, I only want to submit it if you think it's actually like a good idea that they might think is valid. Um, because Jaime has gotten a whole bunch of really bad feedback from the IETF and from Nanog and basically everyone else he's gone to to try to ask them for support of his draft and rightfully so cuz his draft is bat crazy. But, um, that's what happens in the world of the internet, I guess.

[00:25:50]So, I am Apple Art. if you want to support me with what I do. I do sell t-shirts. This is actually Jeff Gearling's t-shirt that says it was DNS.

[00:25:57]I've been thinking of making one that says it was BGP for me. Um because BGP is something I work with more, but uh if you'd be interested in that, I guess let me know. I sell t-shirts, link down below for that. If you want to chat with me about IPv6 migration, Discord server link down below for that as well. And I guess I'll see you guys on the next adventure.