I know, I know: "Kad can't handle IPv6"
Nonetheless, there are a couple of IPv6 emule mods, most notably @zt8989/IronMule (which has been idle for many years) and @petermrg/eNode
Background:
Large tracts of the world are IPv4 constrained and behind CGNAT, which horribly breaks nearly everything except web page access. Entire countries are fronted by CGNAT gateways (eg: for many years Vietnam was only allocated a single /24. All of Myanmar was behind 3 /24s with nested layers of NAT behind that). Chinese users in particular have been driving IPv6 mule quite hard due to IPv4's myriad issues there.
I'm going to refrain from the history lesson, other than to note that IPv4 octets are a red/black routing mechanism designed for a few thousand hosts across ~100 sites which got coopted thanks to the inherent sparseness (by design) that was able to have nearly 4 billion addresses shoehorned into it at a point when there wasn't anything better to cope with the sudden growth of the Internet that started in the late 1980s. BGP and other routing protocols are mostly a horrible kludge that got even kludgier over time. (an IPv4 address could originally be read as "institution.department.campus.host"). There are now upwards of 7 billion devices on the Internet without even getting into localnet-only IoT clusters, making CGNAT a necessity for most providers
Thankfully, the only effective difference from the program's point of view is that the address space is expanded from 32 bit to 128 bit. The program doesn't need to care about all the intricacies and fiddly bits (and in fact you could get away with 64 bits, as a /64 is traditionally one device, so below that level you should only see 1-2 Mule clients). The total number of endpoints doesn't suddenly balloon exponentially, etc and the basic protocol doesn't need any modification other than the addressing.
There have been arguments back and forth about ed2k/kad IPv6 support for 2 decades but IPv4 has sufficiently broken enough (thanks to CGNAT) for long enough that it really needs looking at simply in order to counter the steady netwok rot that comes from people abandoning a system that doesn't work very well anymore. It's not just that hosts tend to get LowIDs, but that they'll get highIDs which become unreachable in a matter of minutes, etc etc. That gets seen by most users as the software being broken rather than network brokenness
It would be worthwhile to see how other mule variants have enabled IPv6 and aim to match that protocol extension.
There's a "unoficial draft for eD2K IPv6 extension" linked off @petermrg/eNode, but the link is broken.
I know, I know: "Kad can't handle IPv6"
Nonetheless, there are a couple of IPv6 emule mods, most notably @zt8989/IronMule (which has been idle for many years) and @petermrg/eNode
Background:
Large tracts of the world are IPv4 constrained and behind CGNAT, which horribly breaks nearly everything except web page access. Entire countries are fronted by CGNAT gateways (eg: for many years Vietnam was only allocated a single /24. All of Myanmar was behind 3 /24s with nested layers of NAT behind that). Chinese users in particular have been driving IPv6 mule quite hard due to IPv4's myriad issues there.
I'm going to refrain from the history lesson, other than to note that IPv4 octets are a red/black routing mechanism designed for a few thousand hosts across ~100 sites which got coopted thanks to the inherent sparseness (by design) that was able to have nearly 4 billion addresses shoehorned into it at a point when there wasn't anything better to cope with the sudden growth of the Internet that started in the late 1980s. BGP and other routing protocols are mostly a horrible kludge that got even kludgier over time. (an IPv4 address could originally be read as "institution.department.campus.host"). There are now upwards of 7 billion devices on the Internet without even getting into localnet-only IoT clusters, making CGNAT a necessity for most providers
Thankfully, the only effective difference from the program's point of view is that the address space is expanded from 32 bit to 128 bit. The program doesn't need to care about all the intricacies and fiddly bits (and in fact you could get away with 64 bits, as a /64 is traditionally one device, so below that level you should only see 1-2 Mule clients). The total number of endpoints doesn't suddenly balloon exponentially, etc and the basic protocol doesn't need any modification other than the addressing.
There have been arguments back and forth about ed2k/kad IPv6 support for 2 decades but IPv4 has sufficiently broken enough (thanks to CGNAT) for long enough that it really needs looking at simply in order to counter the steady netwok rot that comes from people abandoning a system that doesn't work very well anymore. It's not just that hosts tend to get LowIDs, but that they'll get highIDs which become unreachable in a matter of minutes, etc etc. That gets seen by most users as the software being broken rather than network brokenness
It would be worthwhile to see how other mule variants have enabled IPv6 and aim to match that protocol extension.
There's a "unoficial draft for eD2K IPv6 extension" linked off @petermrg/eNode, but the link is broken.