[luckybuilding]

Dear All,
I have been occational user of the emule for the previous decade. I ever wondered why there was no new version for this solution including some needed features such as IPv6!
As this software generates LOW ID for users behind NAT, enabling IPv6 makes more users able to share using High ID.

Would there be any other version for the software soon or not?

Thanks

[Some Support]

There are several reason why there is no IPv6 support:

The most important and practical one: Currently there is not enough development power for the official version to implement such such a major feature. Related to that is the fact that there are unsolved problems: Servers won't support IPv6 (because the server software isn't developed anymore) and for Kad's DHT IPv6 is a security problem (the current one relies on IPs being a scarce ressource to prevent an attacker from impeding / overtaking the network / routing tables and IPv6 isn't scarce anymore). Those issues could most likely be solved - with enough time.

Some mods have done their own implementations already which work, but don't solve the Kad problem (which won't become obvious until it's juicy enough for an attacker to exploit the weakness - so untill the majority of Kad has switched).

[guknos]

Some Support, on 22 December 2016 - 12:00 AM, said:

Servers won't support IPv6 (because the server software isn't developed anymore)

discard servers and use kad only

seriously, do you have some plan for the 0.50b?

This post has been edited by guknos: 22 December 2016 - 06:23 PM

[Angvil]

guknos, on 23 December 2016 - 02:22 AM, said:

Some Support, on 22 December 2016 - 12:00 AM, said:

Servers won't support IPv6 (because the server software isn't developed anymore)

discard servers and use kad only

seriously, do you have some plan for the 0.50b?

Some Support hate IPV6 and NAT-T,and neoloader support IPv6

[Tom999]

Some Support, on 22 December 2016 - 12:00 AM, said:

There are several reason why there is no IPv6 support:

for Kad's DHT IPv6 is a security problem (the current one relies on IPs being a scarce ressource to prevent an attacker from impeding / overtaking the network / routing tables and IPv6 isn't scarce anymore).

I think Kad could learn other P2P protocol which is support IPv6, foe example, BT client BitComet supports IPv6.Besides, NeoLoader also support.

This post has been edited by Tom999: 30 November 2021 - 07:51 AM

[emule_user_downunder]

Anonymity is a feature of peer-to-peer file sharing that is sought by a lot of file sharers. IPv6 has enough unique fixed IP addresses for nearly every atom in the universe, so you will be able to be tracked quite easily. Be careful what you ask for.
Adding another transport layer to eMule as well as the existing eD2K and Kad protocols is not a trivial exercise. Integration is not just ticking another box in your development environment, or just another single 'include' line. It would be great if there were APIs for such an exercise, but that wasn't around when eMule was developed (and as real life will confirm, still isn't).
Who provides the robust support and testing on what has become a mature and stable product over the last few decades?

[Tom999]

emule_user_downunder, on 15 August 2023 - 03:37 AM, said:

Anonymity is a feature of peer-to-peer file sharing that is sought by a lot of file sharers. IPv6 has enough unique fixed IP addresses for nearly every atom in the universe, so you will be able to be tracked quite easily. Be careful what you ask for.

In fact, temporary IPv6 address is enabled by default on Windows, you can see in cmd->netsh interface ipv6 show privacy, I think it will mitigate this.

[megaT]

Same for macOS, this is most likely the default for any modern operating system.
I don't know how (possible) existing eMule mods or fork's have solved this, most likely. they don't talk the same language to each other? (Who does know more?)

If one would want to implement IPv6 for KAD regarding RFC4941 then it would be required that whenever a temporary IPv6 changes that the neighbor nodes get informed about this change.
Another way would be to simply *not use* private addresses, normally the device's fetch both a privacy address and a real... sticky IPv6 address.

[BuyukBang]

Some Support, on 22 December 2016 - 03:00 AM, said:

There are several reason why there is no IPv6 support:

The most important and practical one: Currently there is not enough development power for the official version to implement such such a major feature. Related to that is the fact that there are unsolved problems: Servers won't support IPv6 (because the server software isn't developed anymore) and for Kad's DHT IPv6 is a security problem (the current one relies on IPs being a scarce ressource to prevent an attacker from impeding / overtaking the network / routing tables and IPv6 isn't scarce anymore). Those issues could most likely be solved - with enough time.

Some mods have done their own implementations already which work, but don't solve the Kad problem (which won't become obvious until it's juicy enough for an attacker to exploit the weakness - so untill the majority of Kad has switched).

Hey Some Support,

Can you give details about your security concern on Kad IPv6 support. This is in the to do list of my project, so I'd like to know your point of view.

This post has been edited by BuyukBang: 21 July 2024 - 02:55 PM

[Enig123]

As I understand, while kademlia is vulnerable to eclipse attack, with ipv4 the ip resources attackers could use are limited, but with ipv6 it's another story.

Unfortunately I don't get the ideas ss may have had of how to mitigate that. ss?

[BuyukBang]

Enig123, on 22 July 2024 - 09:58 AM, said:

As I understand, while kademlia is vulnerable to eclipse attack, with ipv4 the ip resources attackers could use are limited, but with ipv6 it's another story.

Unfortunately I don't get the ideas ss may have had of how to mitigate that. ss?

Well, if this is the case, since eMule isn't a financial application, the attackers’ income from this type of attack would be next to zero. I’ve never thought IPv4 is safer and if I remember correctly, the official development team has already announced that privacy has never been a key motivation for eMule in the past. It’s still not in the current codebase. I know of no single case that can’t be tracked with IPv4. Safety requires some investment by the user; for example, using a safe, trustworthy VPN is a good start. But even this could be easily questioned regarding how safe it truly is.

Does anyone know if torrent has added any special IPv6 precautions for the DHT network?

This post has been edited by BuyukBang: 22 July 2024 - 12:38 PM

[DavidXanatos]

Some Support, on 22 December 2016 - 01:00 AM, said:

There are several reason why there is no IPv6 support:

The most important and practical one: Currently there is not enough development power for the official version to implement such such a major feature.

I don't believe this to be true, you wrote this 2016, I have already provided a reference implementation in 2013: howtopic=156977

And just to have this for the record: if there would be a agreement in place to endorse a new eMule client, with updated protocols IPv6 + Nat-T, on the official home page ideally even pushed through the updater, I'll take the time to create it.

Some Support, on 22 December 2016 - 01:00 AM, said:

Related to that is the fact that there are unsolved problems: Servers won't support IPv6 (because the server software isn't developed anymore)

This wasn't true eider: github petermrg eNode sure it says its alpha but it was working and if eMule would support IPv6 one could polish the project to be ready for prime time.

Some Support, on 22 December 2016 - 01:00 AM, said:

... and for Kad's DHT IPv6 is a security problem (the current one relies on IPs being a scarce ressource to prevent an attacker from impeding / overtaking the network / routing tables and IPv6 isn't scarce anymore).

To that I say, keep the KAD IPv4 and let it only index the IPv6 addresses for LowID users, the marginaly higher load for High ID users is more then acceptable, and the benefit to all benefit a Carrier NAT with only an own IPv6 is huge.

The question you (the official Devs) must ask yourselves is whether you want eMule to fade into obscurity or evolve with the times. The lack of IPv6 support is no longer justifiable. The world is moving towards IPv6, and eMule needs to keep up or risk becoming obsolete.

I've already provided a working reference implementation back in 2013, and there are solutions like eNode ready to address the server issues. It's time to modernize eMule with IPv6 and Nat-T support, which would benefit users struggling with Carrier-Grade NAT and ensure eMule's relevance.

If the current team lacks the capacity or interest to drive these necessary updates, perhaps it's time to pass the torch to new developers who are eager and able to take eMule into the future.

[antonymous]

I think the era of small-time solutions like eMule is over. Because all the basic network functionality has already been solved in big FOSS project called IPFS interplanetary filesystem, and much better than a hobbyist project carrying outdated legacy ever could.

A new "eMule" with all the wishlist features would "only" have to bring the classic filesharing UI over to IPFS, so it could be used by anyone.

[BuyukBang]

antonymous, on 28 August 2024 - 08:05 PM, said:

I think the era of small-time solutions like eMule is over. Because all the basic network functionality has already been solved in big FOSS project called IPFS interplanetary filesystem, and much better than a hobbyist project carrying outdated legacy ever could.

A new "eMule" with all the wishlist features would "only" have to bring the classic filesharing UI over to IPFS, so it could be used by anyone.

I agree that IPFS is a promising technology with good use cases. However, from my understanding, P2P file sharing is neither its primary target nor does it excel in this area compared to other use cases. IPFS aims to make everything P2P, which is beneficial for freedom of the Internet, but ed2K already operates in this manner. Data in P2P networks, particularly ed2K, is distributed among users rather than using a server-client model.

Another important point is that it currently has a very limited number of implementations (h ps://docs.ipfs.tech/concepts/ipfs-implementations) at the moment. So, I assume it's still in a stage where it needs to prove itself. Theories can always fail in practice, and there are important topics to be approved: data security, reliability, maintainability, scalability, etc.

And now, the most important thing: there is no official development behind eMule at the moment. The number of active community developers is also very limited. No one here could afford to rewrite or build an entire eMule or a similar P2P application on top of a new technology. This can only be done with reliable funding and a professional team.

This post has been edited by BuyukBang: 29 August 2024 - 01:27 PM

[DavidXanatos]

BuyukBang, on 29 August 2024 - 02:11 PM, said:

And now, the most important thing: there is no official development behind eMule at the moment. The number of active community developers is also very limited. No one here could afford to rewrite or build an entire eMule or a similar P2P application on top of a new technology. This can only be done with reliable funding and a professional team.

I did that by myself with NeoLoader so sure its possible, but me not having funding for marketing was the deal breaker, not the making.

[emule_user_downunder]

Build it and they will come is a saying I have heard before somewhere.
Getting server and client software to be in sync is a big ask. Describe the new functionality you want, define the standard, test it and refine it as you go along. One will drag the other along.
With backward compatibility a feature as well as a millstone around your neck, adding the functionality so more modern clients can benefit from it while retaining the existing functionality is the best of both worlds, and people will be wiling to migrate if they see there is activity and progress, even beta versions that improve and extend the functionality.
The 0.60 community release is proof of that - it is being slowly adopted. Not just bug fixes, but added functionality would be welcome.

This post has been edited by emule_user_downunder: 01 September 2024 - 09:45 AM

[DavidXanatos]

Well, even the community release has only about 20% of a user bases after 5 year, and its even endorsed on the homepage.

This post has been edited by DavidXanatos: 02 September 2024 - 07:09 AM

[Aokromes]

DavidXanatos, on 02 September 2024 - 09:07 AM, said:

Well, even the community release has only about 20% of a user bases after 5 year, and its even endorsed on the homepage.

imho it must be send as update for all the users using previous to 0.70b versions (and tell people to recheck their transfers limits) (maybe even add more speeds like 1 MB/s, 5, 10, 25, 50, 75, 100 for modern connections on 1st startup)